If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Slow script warning from TileManager.js

VERIFIED FIXED

Status

Fennec Graveyard
General
VERIFIED FIXED
7 years ago
4 years ago

People

(Reporter: jdm, Assigned: mbrubeck)

Tracking

Details

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
If I open three tabs to google, I get a slow script warning every time on the third.  Backtrace shows that we're dealing with either MozScrolledArea or MozAfterPaint messages from the child.
(Reporter)

Comment 1

7 years ago
This time I got it on the second tab.  What's interesting is that the backtrace always shows a JIT in progress, as demonstrated in the attachment.
(Reporter)

Comment 2

7 years ago
Created attachment 458867 [details]
Backtrace

JIT in process

Updated

7 years ago
tracking-fennec: --- → ?
(Reporter)

Comment 3

7 years ago
Note that the js_Interpret, js_fun_apply, js_Invoke cycle is evaluating Util.bind as far as I can tell.
(Reporter)

Comment 4

7 years ago
This seems to occur because the browser viewport rectangle contains gigantic numbers after opening a new tab, and the tile manager just keeps chugging away trying to deal with them.  The giant numbers come from the zoomLevel being 800 instead of 1, which in turn comes from the browser viewport being [0,0,1,1] and the zoom level being calculated as page width / viewport right.
Josh tracked this down to bug 557222:
http://hg.mozilla.org/mobile-browser/rev/3f5066602cdb

That call produces the gigantic numbers for viewport and zoomlevel

Updated

7 years ago
Duplicate of this bug: 579084
(Assignee)

Updated

7 years ago
Blocks: 576396
OS: Linux → All
Hardware: x86 → All
(Assignee)

Comment 7

7 years ago
Created attachment 459202 [details] [diff] [review]
patch

This is probably a regression from bug 576396.

This patch is a simple fix, as long as there are no side effects from changing the initial viewport size from 1 pixel to 800.  (There aren't as far as I can tell.  It does not regress bug 557222.)

Do we need some more robust checking in getPageZoomLevel to prevent this from getting triggered some other way?  We do have kViewportMinWidth=200, which prevents pages from setting their own width to 1 pixel.
Assignee: nobody → mbrubeck
Status: NEW → ASSIGNED
Attachment #459202 - Flags: review?(mark.finkle)
Attachment #459202 - Flags: review?(mark.finkle) → review+
pushed:
http://hg.mozilla.org/mobile-browser/rev/f582fa26a29e
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Verified fixed on:
Mozilla/5.0 (Android;Linux armv7l;rv:9.0a1)Gecko/20110920
Firefox/9.0a1 Fennec/9.0a1
Device: HTC Desire
OS: Android 2.2
Status: RESOLVED → VERIFIED
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.