Tooltip hides semitransparent elements since 14-May-2014

VERIFIED FIXED in Firefox 32

Status

()

Core
Layout: View Rendering
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: obrufau, Unassigned)

Tracking

({regression})

32 Branch
mozilla33
regression
Points:
---

Firefox Tracking Flags

(firefox32+ verified, firefox33+ verified)

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Created attachment 8454849 [details]
Screenshot

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:33.0) Gecko/20100101 Firefox/33.0 (Beta/Release)
Build ID: 20140711030201

Steps to reproduce:

1. Create a page filled with with semitransparent elements: `opacity:.5`
2. Force the tooltip to appear, for example with one of these
   - Use a <script> element to get a php script with `sleep(29);` (loading tooltip)
   - Let the semitransparent elements be anchors and hover them (link tooltip)
3. Scroll down


Actual results:

Elements that were hidden by the tooltip remain partially hidden after scrolling.


Expected results:

They should be repainted and made fully visible.

Good: 13-May-2014 4b6d63b05a0a
Bad: 14-May-2014 2f8af55d6e9a
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4b6d63b05a0a&tochange=2f8af55d6e9a

Both Aurora 32 and Nightly 33 are affected.
(Reporter)

Comment 1

4 years ago
Created attachment 8454850 [details]
Demo
(Reporter)

Updated

4 years ago
Component: Untriaged → Layout: View Rendering
Product: Firefox → Core
I can reproduce this on Linux as well.  Probably worth tracking this since
I suspect it will be noticeable by many users.
Status: UNCONFIRMED → NEW
status-firefox32: --- → affected
status-firefox33: --- → affected
tracking-firefox32: --- → ?
tracking-firefox33: --- → ?
Ever confirmed: true
Keywords: regression
OS: Windows XP → All
Hardware: x86 → All
This is probably the same as bug 1025914. I'll back that one out on Aurora as soon as the tree reopens, and on mozilla-central it will be fixed by bug 1022612.
(In reply to Markus Stange [:mstange] from comment #3)
> This is probably the same as bug 1025914. I'll back that one out on Aurora

Er, I'll back out bug 1008301 (which caused this) on Aurora.
(In reply to Markus Stange [:mstange] from comment #4)
> (In reply to Markus Stange [:mstange] from comment #3)
> > This is probably the same as bug 1025914. I'll back that one out on Aurora
> 
> Er, I'll back out bug 1008301 (which caused this) on Aurora.

Will track this for now can you update this bug when the back out is complete.
tracking-firefox32: ? → +
tracking-firefox33: ? → +
Bug 1008301 was backed out on Aurora and bug 1022612 fixed this on Nightly. Since bug 1022612 will get backed out after the imminent uplift, I'll need to back out bug 1008301 at that point, too.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-firefox32: affected → fixed
status-firefox33: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Keywords: verifyme
(In reply to Markus Stange [:mstange] from comment #6)
> Since bug 1022612 will get backed out after the imminent uplift, I'll need
> to back out bug 1008301 at that point, too.

I've done that now.
https://hg.mozilla.org/releases/mozilla-aurora/rev/8c0e169eb2b9
Verified as fixed using the following environment:

FF 32.0b5
Build Id:20140807212602
OS: Win 7 x64, Mac Os X 10.7.5 ,Ubuntu 13.04 x64
status-firefox32: fixed → verified
Reproduced with Nightly 33.0a1 2014-07-12 under Win 7 64-bit.
Verified as fixed using Firefox 33 beta 2 (20140908190852) under Win 7 64-bit, Ubuntu 12.10 32-bit and Mac OSX 10.9.4.
Status: RESOLVED → VERIFIED
status-firefox33: fixed → verified
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.