Closed Bug 1486166 Opened 6 years ago Closed 6 years ago

tooltip does not pop up when mouse over Location Bar


(Firefox :: Address Bar, defect)

60 Branch
Windows 10
Not set



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


(Reporter: alice0775, Assigned: emilio)



(Keywords: regression)


(1 file)

Steps To Reproduce:
1. Shrink browser width so that Location bar will be overflowed
2. Load long URL page
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 = false, the problem is also persists on Firefox 60.
Regression Window:

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.


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

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
Set the tooltip text on the parent of the urlbar input. r=dao
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.
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.