Closed Bug 673122 Opened 9 years ago Closed 9 years ago

Rotating Fennec to landscape causes checkerboard to appear and remain until tap

Categories

(Firefox for Android Graveyard :: General, defect)

All
Android
defect
Not set

Tracking

(firefox8 affected, fennec8+)

VERIFIED FIXED
Firefox 9
Tracking Status
firefox8 --- affected
fennec 8+ ---

People

(Reporter: ajuma, Assigned: stechz)

References

Details

(Keywords: mobile, regression, testcase)

Attachments

(3 files, 1 obsolete file)

Attached image Screenshot
Steps to reproduce:
1) Navigate to a moderately large page (e.g. m.cnn.com) while in portrait mode.
2) Rotate to landscape.

The right 1/3 of the screen will be filled by a checkerboard pattern, which remains until the screen is tapped. (See attached screenshot.)

This issue occurs in the July 20th nightly (http://hg.mozilla.org/mozilla-central/rev/953f9620f395) but not in the July 19th nightly (http://hg.mozilla.org/mozilla-central/rev/a666b4f809f0).
Possibly a regression from Bug 626792 or Bug 668633.
OS: Mac OS X → All
Hardware: x86 → All
Regression window: 

Doesn't occur in http://hg.mozilla.org/mozilla-central/rev/35ed7537c909, 
occurs in http://hg.mozilla.org/mozilla-central/rev/cf0b3329da8c. 

So a regression from bug 626792.
tracking-fennec: --- → ?
I can reproduce this in an Android build, but not in my desktop Linux build.
OS: All → Android
tracking-fennec: ? → 8+
Component: Graphics → General
Product: Core → Fennec
QA Contact: thebes → general
Assignee: nobody → mbrubeck
Assignee: mbrubeck → ben
Ben - this is a high priority issue
We could just back out bug 626792 for now.
I think I know what this is. We have to make sure we wait for the paint before we set the displayport, because content views aren't updated until then.
Attachment #553571 - Flags: review?(mbrubeck)
Attachment #553571 - Flags: review?(mbrubeck) → review+
Backed out bound: http://hg.mozilla.org/integration/mozilla-inbound/rev/4533e6c94fe7 for multiple browser-chrome failures. See http://tbpl.allizom.org/php/getParsedLog.php?id=5997020 and http://tbpl.allizom.org/php/getParsedLog.php?id=5997171 (or the tinderbox URLs when they exist in another six or eight hours).
Try run for 15dff5cd02b3 is complete.
Detailed breakdown of the results available here:
    http://tbpl.mozilla.org/?tree=Try&rev=15dff5cd02b3
Results (out of 2 total builds):
    exception: 2
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bstover@mozilla.com-15dff5cd02b3
Duplicate of this bug: 672779
stover, any update here?
I have a patch. Currently waiting for results from try.
Try run for a59882c85f64 is complete.
Detailed breakdown of the results available here:
    http://tbpl.mozilla.org/?tree=Try&rev=a59882c85f64
Results (out of 16 total builds):
    exception: 1
    success: 15
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bstover@mozilla.com-a59882c85f64
Attachment #553571 - Attachment is obsolete: true
Although the link is not working, the exception above was an infrastructure issue. This one should land fine.
Attachment #554206 - Flags: review?(mbrubeck)
Attachment #554206 - Flags: review?(mbrubeck) → review+
Comment on attachment 554206 [details] [diff] [review]
Rotating Fennec to landscape causes checkerboard to appear indefinitely

Requesting approval to land this fix on Aurora for Firefox 8.  This fixes a user-visible regression that first appeared in Firefox 8.  The fix is mobile-only and low-risk.  (It causes Fennec to refresh the size of its display cache more often, but the additional refreshes will have no effect except where bugs like this have caused the size to get out of sync with the content.)
Attachment #554206 - Flags: approval-mozilla-aurora?
Attachment #554206 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Try run for a59882c85f64 is complete.
Detailed breakdown of the results available here:
    http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=a59882c85f64
Results (out of 16 total builds):
    exception: 1
    success: 15
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bstover@mozilla.com-a59882c85f64
Try run for a59882c85f64 is complete.
Detailed breakdown of the results available here:
    http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=a59882c85f64
Results (out of 16 total builds):
    exception: 1
    success: 15
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bstover@mozilla.com-a59882c85f64
Try run for a59882c85f64 is complete.
Detailed breakdown of the results available here:
    http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=a59882c85f64
Results (out of 16 total builds):
    exception: 1
    success: 15
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bstover@mozilla.com-a59882c85f64
Try run for a59882c85f64 is complete.
Detailed breakdown of the results available here:
    http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=a59882c85f64
Results (out of 16 total builds):
    exception: 1
    success: 15
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bstover@mozilla.com-a59882c85f64
Try run for a59882c85f64 is complete.
Detailed breakdown of the results available here:
    http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=a59882c85f64
Results (out of 16 total builds):
    exception: 1
    success: 15
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bstover@mozilla.com-a59882c85f64
Sorry for the bugspam, trying to update the links and accidentally got caught in a bug posting loop.
Try run for a59882c85f64 is complete.
Detailed breakdown of the results available here:
    http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=a59882c85f64
Results (out of 16 total builds):
    exception: 1
    success: 15
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bstover@mozilla.com-a59882c85f64
I think that's the last one.  If more occur please let RelEng buildduty know to turn off the bugposter for the weekend since I'll be out of town tomorrow and can get back to it on Monday.
http://hg.mozilla.org/mozilla-central/rev/9cc3a0162863
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 9
This issue is still occurring for me (on an up-to-date trunk build).
For me, this is fixed, regarding the str from comment 0, using current trunk build. It takes some longer time, though, before the 1/3 right part of the screen is painted (checkboarding disappears).

Ali, you still have to tap the screen before the checkerboarding disappears?
Duplicate of this bug: 679601
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #29)
> Ali, you still have to tap the screen before the checkerboarding disappears?

Yes, I still have to tap to make the checkerboarding disappear (I waited several seconds to see if it would go away on its own). This is on a Nexus S.
Attached file testcase
Ok, I couldn't reproduce on  m.cnn.com, but I can on this testcase.
The user-scalable=no meta tag is necessary for me to trigger the bug.
Status: RESOLVED → REOPENED
Keywords: testcase
Resolution: FIXED → ---
Works for me.
OK, just reproduced. Could we open a new bug for this?
Ok, I filed bug 681629, I'll mark this bug again as fixed.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Depends on: 681629
I still can see the checkerboard on both m.cnn.com and on testcase page when I'm on Aurora: Mozilla /5.0 (Android;Linux armv7l;rv:8.0a2) Gecko/20110901 Firefox/8.0a2 Fennec/8.0a2

but it's fixed for Nightly: Mozilla /5.0 (Android;Linux armv7l;rv:9.0a1) Gecko/20110901 Firefox/9.0a1 Fennec/9.0a1

Reopen if needed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.