Closed
Bug 1412150
Opened 7 years ago
Closed 7 years ago
Google Docs text sometimes appears too light
Categories
(Core :: Graphics, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla58
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox56 | --- | unaffected |
firefox57 | --- | unaffected |
firefox58 | + | fixed |
People
(Reporter: mcote, Assigned: rhunt)
References
Details
(Keywords: regression, reproducible)
Attachments
(3 files)
921.76 KB,
image/png
|
Details | |
1.92 KB,
patch
|
nical
:
review+
|
Details | Diff | Splinter Review |
3.68 KB,
patch
|
mstange
:
review+
|
Details | Diff | Splinter Review |
I'm using the latest Nightly from 2017/10/26. I do not recall ever seeing this before I updated earlier today. The text on many Google Docs appears, in places, too light (see screenshot). It seems to only occur when there are comments (and maybe only after a certain number of them). The problem seems to come and go as I scroll or hover over comments, although when it manifests it seems to be present more often than not. It makes reading those docs very difficult and annoying.
Comment 1•7 years ago
|
||
¡Hola Mike!
A webcompat thingie perhaps?
¡Gracias!
Alex
Flags: needinfo?(miket)
Reporter | ||
Comment 2•7 years ago
|
||
FYI this is still occurring with this morning's Nightly. I was not able to reproduce it on 56.0.2.
Reporter | ||
Comment 3•7 years ago
|
||
Putting the doc into view mode appears to fix it. Switching back to suggestion mode reveals the bug again. So it really seems related to comments in the doc.
Comment 4•7 years ago
|
||
Mark, could you share that doc with mitaylor@mozilla.com (if it's something I'm allowed to look at) so I can take a look?
Flags: needinfo?(miket) → needinfo?(mcote)
Reporter | ||
Comment 6•7 years ago
|
||
For anyone else wanting to repro: https://docs.google.com/document/d/1QPZG2YObvIsEf8fddJ-DngV2B8C2kL0jjvkXmxBwdfU/edit
Comment 7•7 years ago
|
||
This might be graphics related, I can't reproduce on my machine (win10 or macOS). Also note you need to be logged in with LDAP to see the comments (which are part of STR).
Updated•7 years ago
|
Component: Untriaged → Graphics
Product: Firefox → Core
Reporter | ||
Comment 8•7 years ago
|
||
I have now reproduced it on two Windows 10 machines. One is my work XPS13 laptop. The other is a desktop with a Radeon RX 460. It took a bit more clicking & scrolling to reproduce it on the latter, but not too long (10-15 seconds maybe).
Comment 9•7 years ago
|
||
[Tracking Requested - why for this release]:
I can also reproduce the problem n Windows10 Nightly58.0a1 64bit.
Reproducible: 100%
Steps To Reproduce:
1. Launch Nightly
2. Open https://docs.google.com/document/d/1QPZG2YObvIsEf8fddJ-DngV2B8C2kL0jjvkXmxBwdfU/edit in new tab[A]
3. After complete loading the page, Scroll to the bottom
4. Click [+] button in tabstrip to open a new tab
5. Switch back to the previous tab[A]
Actual Results:
After for a seconds, text becomes too light.
Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4beb0994d438f9dc4f82b44648997913aa5d6355&tochange=b97eefb07e39f92a6bc21be23cb7bb566fbac5cd
Regressed by: bug 1409871
@:rhunt,
your punch of patch seems to cause the regression, Can you look into this?
Blocks: 1409871
status-firefox57:
--- → unaffected
tracking-firefox58:
--- → ?
Flags: needinfo?(rhunt)
Keywords: regression,
reproducible
Updated•7 years ago
|
Priority: -- → P1
Assignee | ||
Comment 11•7 years ago
|
||
Yes, I'll look at this straight away.
Assignee: nobody → rhunt
Flags: needinfo?(rhunt)
Assignee | ||
Comment 12•7 years ago
|
||
Wrong bug number on the commit comment, will fix that later.
I believe this is also the cause behind bug 1412367, as I was no longer able to reproduce that after this fix.
Attachment #8923129 -
Flags: review?(nical.bugzilla)
Updated•7 years ago
|
Status: NEW → ASSIGNED
Has Regression Range: --- → yes
Has STR: --- → yes
status-firefox56:
--- → unaffected
status-firefox-esr52:
--- → unaffected
Updated•7 years ago
|
Version: Trunk → 58 Branch
Updated•7 years ago
|
Attachment #8923129 -
Flags: review?(nical.bugzilla) → review+
Comment 14•7 years ago
|
||
Pushed by rhunt@eqrion.net:
https://hg.mozilla.org/integration/mozilla-inbound/rev/805cb22ff077
Be sure to invalidate the buffer when content changes and we cannot reuse the buffer. (bug 1412150, r=nical)
Assignee | ||
Comment 15•7 years ago
|
||
Comment 17•7 years ago
|
||
Can we please try to land a testcase that would have caught this issue?
Flags: needinfo?(rhunt)
Updated•7 years ago
|
Flags: in-testsuite?
Comment 18•7 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Assignee | ||
Comment 19•7 years ago
|
||
Yes, I will look into adding a test for this.
Flags: needinfo?(rhunt)
Comment 21•7 years ago
|
||
bugherder |
Assignee | ||
Comment 24•7 years ago
|
||
This is a testcase based off of component-alpha-exit-1.html that triggers the regression before the fix.
The test consists of two scrollable divs, with the second one having some text that requires component alpha, but scrolled out of view. The test waits for a paint, then removes the first scrollable div. This causes the second scrollable div to be layerized and given a display port. The display port is big enough to include the text causing the layer to transition to component alpha.
This causes a frame size change, a transition to component alpha, and an overlapping draw region, all of which are necessary to trigger this bug.
Attachment #8925382 -
Flags: review?(mstange)
Comment 25•7 years ago
|
||
Comment on attachment 8925382 [details] [diff] [review]
ca-enter-displayport-change.patch
Review of attachment 8925382 [details] [diff] [review]:
-----------------------------------------------------------------
::: layout/reftests/layers/component-alpha-enter-1.html
@@ +8,5 @@
> +
> + window.addEventListener("MozAfterPaint", function() {
> + // Remove dummy to make scrollbox the first scroll element giving it a
> + // display port. The display port will then contain the text forcing the
> + // layer to transition to component alpha.
Oh, and FrameLayerBuilder will recycle the PaintedLayer from the old scroll frame contents and use it for the contents of the newly-active scroll frame. Maybe that should be added to the comment.
Attachment #8925382 -
Flags: review?(mstange) → review+
Assignee | ||
Comment 26•7 years ago
|
||
Oh I used the wrong bug number. The reftest was pushed with bug 1409871, which is the bug that introduced this regression. See bug 1409871 comment 90.
Assignee | ||
Comment 27•7 years ago
|
||
Per bug 1409871 comment 91, this has a test now.
Flags: in-testsuite? → in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•