Closed Bug 1486166 Opened 6 years ago Closed 6 years ago

tooltip does not pop up when mouse over Location Bar

Categories

(Firefox :: Address Bar, defect)

60 Branch
x86_64
Windows 10
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 63
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 - verified

People

(Reporter: alice0775, Assigned: emilio)

References

Details

(Keywords: regression)

Attachments

(1 file)

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:
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
Blocks: 1440682
[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?
Flags: needinfo?(emilio)
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.
Assignee: nobody → emilio
No longer blocks: stylo-chrome, 1417138
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.
Flags: needinfo?(emilio)
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.
Attachment #9004068 - Flags: review+
See Also: → 1486716
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
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 63
Depends on: 1486957
Blocks: 1486957
No longer depends on: 1486957
Flags: qe-verify+
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.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
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.
QA Contact: mak77
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: