Steps To Reproduce: 1. Shrink browser width so that Location bar will be overflowed 2. Load long URL page e.g, https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/What_are_WebExtensions 3. Mouse over the location bar Actual Results: Nothing popups Expected Desults: URL should pop up Regression window: Regressed by:

Regression window: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7f2dd59744eb4041bc5de60657d931d1a2e9859a&tochange=7a63a457c8e89edc417ea384f24102c988feb3d5 Regressed by: Bug 1417138

The problem worsened further, even if layout.css.servo.chrome.enabled = false, the problem is also persists on Firefox 60. Regression Window: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0dfc8b69311128b0b4cf356a6b7151daf77fa986&tochange=e3cce6ae4b1569a180aba116908d432483fa7b04 Regressed by: e3cce6ae4b15 Emilio Cobos Álvarez — Bug 1440682: Make the XUL tooltip stuff saner. r=enn

[Tracking Requested - why for this release]: The stylo system breaks UI: location bar tooltip. emilio, The stylo system breaks location bar tooltip, Can you please look into this?

Thank you for noticing this Alice. The culprit is bug 1440682, which made the XUL tooltip listeners be properly removed, I think. Will take a look to see what's going on there.

The reason bug 1440682 broke this was because I moved all the code to nsXULElement. However, there was a way for non-XUL elements to get XUL tooltips before that, which was via the RestyleManager mechanism to handle attribute mutations. So the behavior before that patch was that non-XUL elements that got the attribute dynamically added or removed before that patch got their tooltips, like the HTML input in the toolbar, but if you specified the attributes statically in the markup, or while the element was somehow outside of the document or what not, it would never work. Given that, this looks completely unintentional, and the fact that this ever worked was a bit lucky. Chances are we eventually want tooltip support for HTML elements in chrome documents, but it is pretty likely that we want to use the HTML tooltip infrastructure instead of nsXULTooltipListener, which is kind of an odd thing. Thus, for now patch the code so that it sets it on the container of the <input>, which is a XUL box that takes the same space as the <input>, instead of moving all the XUL tooltip support to work on non-XUL elements. Also, while at it, remove references to inputtooltiptext, since I didn't find a single reference in the code that would set this attribute ever.

Does the title attribute not work on the input?

(In reply to Dão Gottwald [::dao] from comment #6) > Does the title attribute not work on the input? Doesn't look like it, nope.

Not a new regression, doesn't quite seem worth tracking.

Comment on attachment 9004068 [details] Set the tooltip text on the parent of the urlbar input. Dão Gottwald [::dao] has approved the revision.

Pushed by emilio@crisal.io: https://hg.mozilla.org/integration/mozilla-inbound/rev/20a43066e367 Set the tooltip text on the parent of the urlbar input. r=dao

Reproduced the issue on FF Nightly 63.0a1 (2018-08-24) (64-bit) on Windows 7/10, Ubuntu 16.04 and Mac OS 10.13. The issue is Verified - Fixed since it can no longer be reproduced on the latest Nightly 63.0a1 (2018-08-31)(20180831100058) on all the above mentioned OS.

This doesn't seem like an issue that warrants ESR consideration, but feel free to nominate it and make your case if you feel strongly otherwise.