[GOOGLE CHROME] - Clicking a line doesn't navigate to it

[xps64x]

After the latest update of Google Chrome, after searching for anything in opengrok, when you click on a specific line in the search results, it opens the top of the file and doesn't navigate anymore to the line selected. It works fine in other browsers like Firefox. Was anyone able to find a workaround or was a solution found for this issue?

[idodeclare]

I'm not able to corroborate your issue using latest Chrome Version 83.0.4103.61 (Official Build) (64-bit) on macOS. It works for me.

I recorded in Chrome using Developer Tools and saw the scrollIfAnchor function called (below). What do you see if you likewise trace in your Chrome?

[xps64x]

I tried recording in Developer Tools int the Performance section. However, I couldn't get to the scrollIfAnchor function. Could you please help in telling me how to get there?

[idodeclare]

@rbikai, you can try searching in the Call Tree. Note however that it will only find items that are visible in the timeline.

Following is an example where I'm zoomed in on a particular area where scrollIfAnchor is not seen, so the search result (bottom of image) does not find anything.

You could zoom out to the entire timeline to expand the search as shown below where the function is found (bottom of image).

[xps64x]

@idodeclare , thanks for your answer. I tried as you said but I couldn't find the function you see.

[idodeclare]

@rbikai, that's good to confirm that something is interfering with OpenGrok's JavaScript.

Is there any Chrome extension you're using that might be blocking JS? Or if you're running from a company installation, I wonder if some new Chrome setting would block JS.

[xps64x]

@idodeclare there are no JS settings related that are enforced on the machines. I did check the site permissions and JS is enabled. I tried enabling flash as well but nothing happens. Do you have an idea how we could trace what's blocking JS on Chrome?

[ktulinger]

Any chance you're using greasemonkey?

[xps64x]

@ktulinger no I'm not, it's not even installed

[idodeclare]

@rbikai, perhaps I was premature to accuse JS.

I notice now that your URL doesn't seem to include a fragment identifier for the line. E.g., for a URL I tested, after scroll has happened my location shows as ending with /hash_function_defaults.h?r=5d49f79c#133 where the fragment identifier #133 is what triggers the scroll.

The link from the search page would have ended with just e.g. /hash_function_defaults.h#133. OpenGrok looks up the revision ID (?r=5d49f79c), and redirects to include that. The fragment identifier survives the redirect thanks to browsers following the standard (see Handle the fragment identifier of a URI when the HTTP request is redirected).

Can you confirm that what you click in the search window has a line-number fragment identifier?

(As an aside, not all fragment identifiers survive redirect. The fragment identifier has to have been on a browser link the user clicks.

For the recent #3053, to fix where the backend search redirects to a listing with a fragment identifier [e.g. /hash_function_defaults.h#Class234] that the user did not click, in that case the fragment identifier was not surviving another redirect to include the revision ID [e.g. to /hash_function_defaults.h?r=49f79c5d#Class234]. Special handling was needed to mediate the fragment identifier to the second redirect.)

[classigit]

I have the same issue. The weird thing is that if I manually edit the URL in the address bar: for example /myfile.txt#471 --> /myfile.txt#470 and press enter it jumps to the right line.

[kamleshbhalui]

I am also seeing the same problem but only with chrome, Mozilla is working fine.

[ricebus]

I have the same issue. The weird thing is that if I manually edit the URL in the address bar: for example /myfile.txt#471 --> /myfile.txt#470 and press enter it jumps to the right line.

Exactly the same here

[sadaaithal]

hi, is there an update to opengrok that fixes this issue on chrome?

and I can confirm that if I do what @classigit says then chrome scrolls the page right down to the line number.

[idodeclare]

I've never been able to reproduce, and I confirm now it's working fine for me with Chrome version 87.0.4280.88 (Official Build) (x86_64) (macOS).

May I ask what version you have?

[sadaaithal]

Hi @idodeclare - I'm on the same, but Windows. I thought the ublock extension ( and some others) could be causing the problem. I just disabled all of them and I still see the issue. Is there an opengrok build version I can check? Maybe that is what is different..

[idodeclare]

Libre Office team generally maintains their public OpenGrok instance at the latest release (within a couple of days).

I just succeeded verifying scroll-to-line with the Windows version of Chrome version 87.0.4280.88 (Official Build) (64-bit) via a query of https://opengrok.libreoffice.org/search?full=synchronized&defs=&refs=&path=&hist=&type=&xrd=&nn=19&searchall=true.

If you hover over the "served by {OpenGrok" image at the bottom, for releases within the last couple of years or so, OpenGrok pops up the release number and commit hash. E.g. for Libre Office: "1.5.11 - ecb835e".

[sadaaithal]

I dont see a that. looks like this is an older version.

And i think this is what is causing the problem. Let me work on getting this upgraded thank you!

[idodeclare]

Please click that libreoffice query I sent above, and see if scroll-to-line works for you on the resulting links.

[sadaaithal]

that works. and i did one better - i went over to another one of our opengrok instances from another team and sure enough, scroll works there on chrome they are not on the latest, but definitely newer than mine

i will upgrade our grok instance.