Closed Bug 709778 Opened 13 years ago Closed 13 years ago

Aggressive canvas or viewport resizing on page load

Categories

(Firefox for Android Graveyard :: General, defect, P2)

ARM
Android
defect

Tracking

(fennec11+)

RESOLVED DUPLICATE of bug 709492
Tracking Status
fennec 11+ ---

People

(Reporter: aaronmt, Assigned: pcwalton)

Details

On load of CNN.com as an example site, I see what seems to be some sort of aggressive canvas resizing which is rather annoying (why is it red?)

[1] http://www.youtube.com/watch?v=dqn5itFR61c

I dont visually see this behaviour in any other browser.

Samsung Galaxy SII (Android 2.3.6)
20111211040259
http://hg.mozilla.org/integration/mozilla-inbound/rev/f5578fdc50ef
Opening about:home from preferences does the same thing too.
Also see this opening the Add-ons Manager in an hourly from (12/13)

20111213113518
http://hg.mozilla.org/mozilla-central/rev/a111d03d465c
also repro'd this when loading planet.mozilla.org.  

SGS2, 12-16-2011 nightly.

one way to reproduce is to keep tapping the canvas area as the page is still loading.  screen tries to resize like a madman, and eventually it turned red.
Assignee: nobody → pwalton
Priority: -- → P2
Still reproducible, still annoying
Summary: Aggressive canvas resizing on page load? → Aggressive canvas resizing on page load
Version: unspecified → Trunk
Summary: Aggressive canvas resizing on page load → Aggressive canvas or viewport resizing on page load
Is this a dupe of bug 709492 or is it something else?
It's different. In fact, it's a dupe of bug 711232, and should be fixed. It's red because it's scaling the 1x1 pixel in the top-left corner to the entire viewport.
It occurs to me that my previous patch will not help much with the very first tab loaded, because gScreenWidth and gScreenHeight will be zero or one. The patch on bug 710297 should improve this further, but initializing gScreenWidth and gScreenHeight to screen-size should also take care of this. The problem is we don't have the screen size at that point, and so maybe a better solution is to not do a draw at all until we have the screen size in browser.js.
Bug 711232 is fixed, but this really seems like a dupe of bug 709492. If this bug is not actually fixed, I assume this a dupe of bug 709492 and marking as such.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
tracking-fennec: --- → 11+
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.