Open
Bug 1414870
Opened 7 years ago
Updated 2 years ago
Purple background when using find in page feature in private mode
Categories
(Firefox :: Tabbed Browser, defect, P2)
Tracking
()
People
(Reporter: yoasif, Unassigned)
References
Details
(Keywords: nightly-community, regression)
Attachments
(2 files)
7.88 MB,
video/quicktime
|
Details | |
941 bytes,
patch
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID: 20171106100122 Steps to reproduce: 1. Open Firefox 2. Open Private Browsing mode 3. Navigate to any page 4. Do Command+F Actual results: The area where the find bar appears briefly shows a purple background Expected results: No purple background. 29:34.87 INFO: No more inbound revisions, bisection finished. 29:34.87 INFO: Last good revision: f89ae3c450ce33915e4d2fff0b11b942dec17f1a 29:34.87 INFO: First bad revision: 0e14317d2f6c454e86549fe84d6067e1745a76c5 29:34.87 INFO: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f89ae3c450ce33915e4d2fff0b11b942dec17f1a&tochange=0e14317d2f6c454e86549fe84d6067e1745a76c5
Reporter | ||
Updated•7 years ago
|
status-firefox57:
--- → affected
status-firefox58:
--- → affected
tracking-firefox57:
--- → ?
tracking-firefox58:
--- → ?
Component: Untriaged → Tabbed Browser
Keywords: nightly-community,
regression
Version: 58 Branch → 57 Branch
Reporter | ||
Comment 1•7 years ago
|
||
Comment 2•7 years ago
|
||
Too late for a fix for 57. We could still take a patch for 58, but I don't think release management needs to track this bug.
Comment 3•7 years ago
|
||
Florian, could you please look into this?
Flags: needinfo?(florian)
Priority: -- → P2
Comment 4•7 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #3) > Florian, could you please look into this? Not this week, but yes I indent to have a look.
Reporter | ||
Comment 5•7 years ago
|
||
Was able to reproduce this on Linux and macOS.
OS: Unspecified → All
Comment 6•6 years ago
|
||
https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Move_fix-optionals
status-firefox59:
--- → ?
Comment 7•6 years ago
|
||
The problem here is the opacity transition. This was added in bug 836867, I don't understand why we need to transition both the opacity and the visibility properties. The attached wip removes the 'opacity' transition. That seems to fix the bug for me locally and I didn't notice any side effect. Jared, do you happen to remember why in bug 836867 you made the opacity transition? (Yeah, I know it was 5 years ago...)
Flags: needinfo?(florian) → needinfo?(jaws)
Comment 8•6 years ago
|
||
This is because a transition on visibility does not interpolate between collapsed and visible. It is always a step function for visibility. However we can use opacity to fade in the toolbar, which does allow for interpolation. We use visibility: collapse to "hide" the toolbar so it doesn't consume any visible area, but not display:none; as display is not a transitional property. So to show the toolbar we change visibility to visible with a 0s delay, while we delay the other properties by 150ms. The opposite is used for hiding the toolbar. In the case of showing, this allows the toolbar to consume visible area with transparency, then slide up and fade in the toolbar 150ms later.
Flags: needinfo?(jaws)
Reporter | ||
Updated•6 years ago
|
status-firefox65:
--- → affected
tracking-firefox65:
--- → ?
Comment 9•6 years ago
|
||
Happy to take a fix in 65 or soon, 66, but I don't think release management needs to track this bug.
status-firefox63:
--- → wontfix
status-firefox64:
--- → wontfix
Comment 10•5 years ago
|
||
Happy to take a patch in nightly; if it seems low risk enough please feel free to request uplift to 65 beta.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•