User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID: 20180122225545 Steps to reproduce: Find a link that has an onclick or other JavaScript mechanism to change the link when it is clicked. E.g. the links to external sites that users post to Facebook. Right-click this link and while watching the URL in the "status bar" at the bottom of the window. Actual results: The URL doesn't change, even though the event has been triggered and the link has been modified. If the page is like Facebook and sets the link back after a timeout, hovering over the link before the timeout will show the modified link, and likewise the URL in the status bar will not be updated when the timeout occurs that the URL reverts. Expected results: The URL in the status bar should always be the actual URL of the link in that moment.

Paul, would you please attach a reduced test case or a recording displaying the problem? I'm a bit confused on the right-click part: (In reply to Paul from comment #0) > Right-click this link and while watching the URL in the "status > bar" at the bottom of the window. Did you mean left click?

I do mean right click, because Facebook alters the URI on right clicks. You can see it doing this if you inspect the external link before right clicking it. It actually doesn't seem to do so for left and middle clicks, maybe because Facebook has a different mechanism to discovers that you've clicked (e.g. the Beacon API). For a reduced test case with *left* clicking, see this page: https://jsfiddle.net/mipo/yJn3N/1/ Inspect the "Click here" link, then watch what happens to both the inspected link's href and the URL in the status bar when you click it. You will see that the href is updated the instant that you click, but the status bar does not update until you roll the cursor off the URL and roll back on. (The code only changes the URL twice, then you need to reload the page.)

Thanks Paul, with comment 2 now, I've spotted the issue I've missed in the initial report. IMO, this is a valid bug unless we're missing something for which the status bar was designed to behave like this. Mike, since you are a bit familiar with this code, any thoughts on this behavior? (this is not a regression from bug 1307134 or a recent regression)

At least Firefox's behaviour is consistent. In Chromium the status bar updates as expected ... but only on the first click. The second time you click the link, Chromium's status bar doesn't update until you move the mouse pointer at least one pixel ... even if you moved the pointer off the link and then back on before clicking. And in the case of Facebook, Chromium's status bar does update for right clicks, but again only the first time. On subsequent clicks, the status bar disappears entirely, even if you move the cursor. It only returns if you move off the link and back on. Bizarre.

(In reply to Adrian Florinescu [:AdrianSV] from comment #3) > IMO, this is a valid bug unless we're missing something for which the status > bar was designed to behave like this. Mike, since you are a bit familiar > with this code, any thoughts on this behavior? (this is not a regression > from bug 1307134 or a recent regression) Sounds like a legitimate bug, for sure. I can easily reproduce it. Thanks, Paul, for the test case. Tentatively moving this over to Tabbed Browser for now, since I think that's where the code that updates the floating status bar resides.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #5) > Tentatively moving this over to Tabbed Browser for now, since I think that's > where the code that updates the floating status bar resides. That's kind of true (it's XULBrowserWindow.setOverLink to be precise), but that code doesn't have control over when it gets called. Gecko would be responsible for calling setOverLink in order to update a link's URL while it's being hovered.

It seems reasonable to fix this (update the tooltip while it's showing), but note that the page can still hide this if they want to, e.g., by using window.location to navigate instead. Peter, you want to have a look?

The reporter of bug #1468727 has created an onmouseover test https://www.w3schools.com/code/tryit.asp?filename=FSB2DJHIGFTV which demonstrates the following variations on this behaviour in Firefox 60: 1. Does not update the preview link on hover 2. Does change the preview link on click, but only the first time 3. Doesn't change the preview link on subsequent clicks until the page is reloaded 4. Always shows the correct preview link post facto if tapped using a touchscreen Is that relevant to this bug too?

Duping forward by exception because the dupe has an idea on how to address this in Ehsan's comment.