[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