User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Steps to reproduce: I scroll a semi-opaque <div> then hover the mouse cursor on a semi-opaque image inside the <div>. Actual results: the semi-opaque image disappears... JSFiddle link to better illustrate: https://jsfiddle.net/qukxa8r6/15/ Expected results: the semi-opaque image should become opaque or be as opaque as the <div> containing it. ie: opacity: 1;
It appears only with e10s enabled. As e10s has been enabled for many users since FF52, that's why you think the issue appears in FF52. But the bug is present in previous versions with e10s turned on.
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout
Ever confirmed: true
Product: Firefox → Core
Summary: image in scrollable <DIV> disappears with image:hover → [e10s] Image in scrollable <DIV> disappears with image:hover
It regressed after bug 1172239 (only with e10s enabled): https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b0b3dcfa5557&tochange=d3228c82badd But the blinking has been partilly fixed after FF45, but it's still visible (footer of the image): https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=47b49b0d32360fab04b11ff9120970979c426911&tochange=66a6d7ec9534b9d7847b665142fef0dd87623768
status-firefox52: --- → affected
status-firefox53: --- → affected
status-firefox54: --- → affected
status-firefox55: --- → affected
status-firefox-esr52: --- → affected
Version: 52 Branch → 42 Branch
(In reply to Loic from comment #3) > It regressed after bug 1172239 (only with e10s enabled): > https://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=b0b3dcfa5557&tochange=d3228c82badd > I get a different regression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=738d8ee106fe&tochange=af67b5f73381
(In reply to Alice0775 White from comment #4) > (In reply to Loic from comment #3) > > It regressed after bug 1172239 (only with e10s enabled): > > https://hg.mozilla.org/mozilla-central/ > > pushloghtml?fromchange=b0b3dcfa5557&tochange=d3228c82badd > > > > I get a different regression range: > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=738d8ee106fe&tochange=af67b5f73381 The regression range from comment 3 actually includes the regression range from comment 4. So that means it's probably comment 4 that indicates which bug caused this.
With e10s turned on and apz on and I can reproduce. With e10s turned on and apz turned off I cannot reproduce. So it's a bug with APZ.
I tried finding the regression range with the pref layers.async-pan-zoom.enabled force enabled, but I'm not 100% sure it's correct. This is what I got https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b6623a27fa64&tochange=c6bbf8f1b02b
Regression window about image disappearing partially with forcible enabled e10s and APZ: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b72b79f155ac&tochange=fd1115daa8c4 Regressed by : Bug 1148582
status-firefox52: affected → wontfix
status-firefox53: affected → wontfix
bug 1148582 is probably not interesting as a starting point since it was the start of a large and complicated effort to get clips right.
I'm not an expert with Windows, but in my experience debugging Assembler: The trigger of the bug is not necessarily its source. I believe the more important question is. Why doesn't the bug trigger when: 1. the image:hover opacity is < 0.99 but does on >= 0.99 2. just one character is added to the contenteditable <div>
Priority: -- → P3
Since this has gone in the backlog bucket, marking fix-optional.
status-firefox54: affected → fix-optional
status-firefox55: affected → fix-optional
You need to log in before you can comment on or make changes to this bug.