Closed Bug 681629 Opened 9 years ago Closed 8 years ago
Rotating Fennec to landscape causes checkerboard to appear and remain until tap, part 2
Ali is still able to reproduce bug 673122. Steps to reproduce: 1) Navigate to a moderately large page (e.g. http://m.cnn.com ) while in portrait mode. 2) Rotate to landscape. This is what Ali sees as a result. https://bugzilla.mozilla.org/attachment.cgi?id=547400 I couldn't reproduce it, but I can reproduce the issue with this testcase https://bugzilla.mozilla.org/attachment.cgi?id=555076
Was able to produce checkerboarding in portrait view only by going to file:///
See testcase in comment 0 to reproduce.
Priority: -- → P3
Mozilla/5.0 (Android; Linux armv7l; rv:9.0a1) Gecko/20110830 Firefox/9.0a1 Fennec/9.0a1 Not seeing this on trunk with the URL in comment #0. How is this bug different than the other checkerboarding bugs?
Which checkerboarding bugs do you mean? This is a follow-up from bug 673122.
I can still reproduce this on current Nightly, using Android 2.2 on the LG Optimus Black.
This seems to be timing-sensitive. Bug 673122 originally occurred on (most?) Android devices but not on desktop. The patch there changed the timing of the displayport updates, but perhaps the new timing is still not correct on devices with certain performance profiles.
This happened to me every time I go to neowin.net.
The checkboard only shows for a few seconds in http://m.cnn.com In neowin.net it showed only the first time. Mozilla/5.0 (Android; Linux armv7l; rv:9.0a 1)Gecko/20110909 Firefox/9.0a1 Fennec/9.0a1 Samsung Galaxy Tab 10.1
(In reply to Matt Brubeck (:mbrubeck) from comment #7) > This seems to be timing-sensitive. Bug 673122 originally occurred on > (most?) Android devices but not on desktop. The patch there changed the > timing of the displayport updates, but perhaps the new timing is still not > correct on devices with certain performance profiles. A basic timeline of what I believe is happening: 1) Resize is issued 2) MozScrollAreaChanged is fired 3) MozAfterPaint is fired but not the one related to the resize paint 4) The resize paint occurs but nobody is listening As I said in bug 673122, if we update the displayport before the parent process has received the new surfaces, we will update for the wrong dimensions. The problem is that we need to know when the paint for the resize occurs so that we update the displayport with the new dimensions. A platform fix might be to fire a parent-side event whenever the dimensions of a view change, which is exactly the time we need to change the displayport. If we had this we could probably remove all the size tracking in the parent process as well (nice bonus!). A mobile fix is to back out the code that started this and continue relying on tracking MozScrollAreaChanged events to update the main displayport, since right now there are two different ways we get the size of the page (through the view API and what we cache on the browser element).
Mass resolving XUL Fennec I filed to WORKSFORME. If someone still cares about this bug, please reopen.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.