Closed
Bug 1255054
Opened 8 years ago
Closed 8 years ago
Possible to get perma-checkerboarded after resizing window
Categories
(Core :: Panning and Zooming, defect)
Core
Panning and Zooming
Tracking
()
VERIFIED
FIXED
mozilla48
People
(Reporter: kats, Assigned: kats)
References
Details
(Keywords: correctness, Whiteboard: [gfx-noted])
Attachments
(1 file)
3.70 KB,
patch
|
BenWa
:
review+
ritu
:
approval-mozilla-aurora+
ritu
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
While trying to reproduce bug 1250422 I ran into a scenario that can result in perma-checkerboarding. On Windows for example, if you have a window and resize it to be shorter, the displayport suppression kicks in and makes the displayport smaller. After you're done resizing, scroll down (mousewheel with APZ). Now the paint-skipping kicks in and avoids scheduling paints because it thinks you're still in the displayport - it uses the non-suppressed displayport check but the last painted displayport was a suppressed one. So you can scroll right into checkerboarding without layout scheduling a paint. If you scroll far enough eventually layout will schedule a paint but it's possible that on short pages that never happens. This is a combination of effects from bug 1186662 and bug 1187432 (aggravated by bug 1192910).
Assignee | ||
Updated•8 years ago
|
Assignee | ||
Comment 1•8 years ago
|
||
If we schedule a paint after unsuppressing, as per https://bugzilla.mozilla.org/show_bug.cgi?id=1202503#c10, that should fix this problem.
Depends on: 1202503
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → bugmail.mozilla
Assignee | ||
Comment 2•8 years ago
|
||
Actually I'll put the patch on this bug rather than bug 1202503 since that one might have other issues mixed in.
Assignee | ||
Comment 3•8 years ago
|
||
Attachment #8728571 -
Flags: review?(bgirard)
Comment 4•8 years ago
|
||
Comment on attachment 8728571 [details] [diff] [review] Schedule a paint after unsuppressing so we don't get stuck with a suppressed displayport Review of attachment 8728571 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/ipc/TabChild.cpp @@ +2381,5 @@ > child->Destroy(); > } > > while (mActiveSuppressDisplayport > 0) { > + APZCCallbackHelper::SuppressDisplayport(false, nullptr); This might be a reason to split SuppressDisplayport into SuppressDisplayport and UnsuppressDisplayport since it doesn't need a preshell. I'll leave that up to you. ::: gfx/layers/apz/util/APZCCallbackHelper.cpp @@ +919,5 @@ > if (aEnabled) { > sActiveSuppressDisplayport++; > } else { > sActiveSuppressDisplayport--; > + if (sActiveSuppressDisplayport == 0 && aShell && aShell->GetRootFrame()) { Do we want to allow unsupressing without a shell? This would lead to this bug again in a situation that might be harder to reproduce? If we have a good reason than perhaps it should be documented. Otherwise this should be an assert.
Assignee | ||
Comment 5•8 years ago
|
||
Comment on attachment 8728571 [details] [diff] [review] Schedule a paint after unsuppressing so we don't get stuck with a suppressed displayport Review of attachment 8728571 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/layers/apz/util/APZCCallbackHelper.cpp @@ +919,5 @@ > if (aEnabled) { > sActiveSuppressDisplayport++; > } else { > sActiveSuppressDisplayport--; > + if (sActiveSuppressDisplayport == 0 && aShell && aShell->GetRootFrame()) { Ideally no, but one of the callsites is from TabChild::RecvDestroy - it might not have a presShell at that point, and even if it did, calling SchedulePaint on it will likely not have any real effect. So in that case I figured it was ok to be passing in null. I can document though that we really want a presShell as much as possible.
Comment 6•8 years ago
|
||
Comment on attachment 8728571 [details] [diff] [review] Schedule a paint after unsuppressing so we don't get stuck with a suppressed displayport Review of attachment 8728571 [details] [diff] [review]: ----------------------------------------------------------------- r+, a comment would be nice.
Attachment #8728571 -
Flags: review?(bgirard) → review+
Assignee | ||
Comment 8•8 years ago
|
||
Added a comment in the header and landed. There might be some talos fallout from this, but hopefully it will be negligible.
Comment 9•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4c7653f68de6
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox48:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Assignee | ||
Comment 10•8 years ago
|
||
Comment on attachment 8728571 [details] [diff] [review] Schedule a paint after unsuppressing so we don't get stuck with a suppressed displayport Approval Request Comment [Feature/regressing bug #]: combination of bug 1186662 and bug 1187432 when APZ is enabled [User impact if declined]: it's possible to get into a state with checkerboarding showing on the screen that doesn't clear itself. you have to scroll or switch tabs or something to force it to go away [Describe test coverage new/current, TreeHerder]: tested locally, on m-c [Risks and why]: small patch, pretty low risk [String/UUID change made/needed]: none
Attachment #8728571 -
Flags: approval-mozilla-beta?
Attachment #8728571 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 11•8 years ago
|
||
[Tracking Requested - why for this release]: pretty bad user experience in a particular scenario with APZ enabled.
status-firefox46:
--- → affected
status-firefox47:
--- → affected
tracking-firefox46:
--- → ?
tracking-firefox47:
--- → ?
Comment on attachment 8728571 [details] [diff] [review] Schedule a paint after unsuppressing so we don't get stuck with a suppressed displayport regression fix in APZ, taking it.
Attachment #8728571 -
Flags: approval-mozilla-beta?
Attachment #8728571 -
Flags: approval-mozilla-beta+
Attachment #8728571 -
Flags: approval-mozilla-aurora?
Attachment #8728571 -
Flags: approval-mozilla-aurora+
Comment 14•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/edcc2ad52ece
Comment 15•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/9f0b9e629896
Updated•8 years ago
|
Flags: qe-verify+
Comment 16•8 years ago
|
||
I couldn't reproduce the bug as described in comment 0, so I tried to see the duplicate, bug 1202503: in an older Nightly I could see the flashing on the first scroll. This behavior doesn't reproduce on latest versions (46, 47, 48). Still, there are two issues when resizing a window to be shorter: repaint (all platforms) - logged bug 1261355 and stretch content (specific to Windows) - tracked in bug 1256728 and bug 1251778. Marking as verified based on this.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•