tooltip does not pop up when mouse over Location Bar

VERIFIED FIXED in Firefox 63

Status

()

defect
VERIFIED FIXED
11 months ago
8 months ago

People

(Reporter: alice0775, Assigned: emilio)

Tracking

({regression})

60 Branch
Firefox 63
x86_64
Windows 10
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox-esr60 wontfix, firefox61 wontfix, firefox62 wontfix, firefox63- verified)

Details

Attachments

(1 attachment)

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
https://hg.mozilla.org/mozilla-central/rev/20a43066e367
Status: NEW → RESOLVED
Closed: 11 months 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
Duplicate of this bug: 1511659
You need to log in before you can comment on or make changes to this bug.