tooltips are blank when mouse hover over icons in addressbar
Categories
(Firefox :: Address Bar, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox71 | --- | unaffected |
firefox72 | + | verified |
firefox73 | + | verified |
People
(Reporter: alice0775, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
Attachments
(5 files)
Reproducible: 1/2
Steps to reproduce:
- Open newtab and load wikipedia
- Mouse hover over icon in addressbar
- Switch tab back
- Load https://helpx.adobe.com/flash-player.html and wait for loading
- Mouse hover over icon in addressbar
Actual results:
tooltips are blank. After I tried 2-3 times, the tooltip display properly
See attached screencast
Expected Results:
tooltip should display properly
Reporter | ||
Comment 1•5 years ago
|
||
this seems to be regressed by Bug 1596990
Comment 2•5 years ago
|
||
:alice0775, if you think that's a regression, then could you try to find a regression range in using for example mozregression?
Reporter | ||
Comment 3•5 years ago
|
||
(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #2)
:alice0775, if you think that's a regression, then could you try to find a regression range in using for example mozregression?
(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #2)
:alice0775, if you think that's a regression, then could you try to find a regression range in using for example mozregression?
Steps to reproduce:
1.Open newtab and load wikipedia
2.Mouse hover over padlock icon in addressbar
3. Load https://helpx.adobe.com/flash-player.html and wait for loading
4. Mouse hover over padlock icon in addressbar
Actual results:
tooltips are blank. After I tried 2-3 times, the tooltip display properly
See attached screencast
Expected Results:
tooltip should display properly
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=038ebfdd141acdc7603d2378a832a572bb267686&tochange=9644ee96a51a03a8f4e50e9777fb7278f246383c
So, Bug 1492582 is culprit
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 4•5 years ago
|
||
I can also reproduce the issue on Nightly72.0a1 on Ubuntu18.04
Reporter | ||
Comment 5•5 years ago
|
||
Updated•5 years ago
|
Comment 6•5 years ago
|
||
Hey Alice,
I can also reproduce this on Windows 10 x64. Let's move it over to a component to get this issue tracked.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 7•5 years ago
|
||
Otherwise code like StyleChildrenIterator won't find it, plus it is the right
thing to do anyway.
You don't really want this to inherit from the root element, even though given
this content is under our control (only in chrome documents) it is less of an
issue.
Assignee | ||
Comment 8•5 years ago
|
||
Hopefully you don't mind me stealing this Brendan :)
Assignee | ||
Comment 9•5 years ago
|
||
Comment 10•5 years ago
|
||
Unfortunately, I can still reproduce the issue with that patch.
- Open firefox
- add new tab
- open https://www.mozilla.org/en-US/privacy/firefox/
- hover over lock icon until tooltip shows
- click back to first tab
- load https://helpx.adobe.com/flash-player.html (while that loads keep moving your mouse around in the browser chrome)
- when the manage plugin icon appears, mouse over that
Comment 11•5 years ago
|
||
Like Alice noted, if you move around between tooltips they'll start working correctly again. Though you can re-break them, by repeating steps 2-7 again.
Assignee | ||
Comment 12•5 years ago
|
||
Blerg, silly mistake, fixed. Sanity-checking it actually fixes it appreciated, you seem to be able to repro much more consistently than me :)
Comment 13•5 years ago
|
||
Comment 14•5 years ago
|
||
bugherder |
Comment 16•5 years ago
|
||
Reproduced once more on affected Beta 72.0b7 (64-bit) on Windows 10 and Ubuntu 18.04.
Verified-fixed on Firefox Nightly 73.0a1 (2019-12-16) (64-bit) on Windows 10 and Ubuntu 18.04
Waiting for uplift to Beta.
Assignee | ||
Comment 17•5 years ago
|
||
Comment on attachment 9115015 [details]
Bug 1598841 - nsCanvasFrame anonymous content needs to be document-level. r=bdahl
Beta/Release Uplift Approval Request
- User impact if declined: see comment 0
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: comment 0
- List of other uplifts needed: none
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Straight-forward change.
- String changes made/needed: none
Updated•5 years ago
|
Comment 18•5 years ago
|
||
Comment on attachment 9115015 [details]
Bug 1598841 - nsCanvasFrame anonymous content needs to be document-level. r=bdahl
regression fix affecting the address bar, verified in nightly, approved for 72.0b8
Comment 19•5 years ago
|
||
bugherder uplift |
Comment 20•5 years ago
|
||
Reproduced the issue on Beta 72.0b7 (Build id: 20191213132525) on Windows 10 and Ubuntu 18.04.
Verified-fixed on latest Beta 72.0b11 (Build id: 20191227034945) using Windows 10 and Ubuntu 18.04.
Description
•