start page zoomed too big when another tab is opened at start

VERIFIED FIXED

Status

Fennec Graveyard
General
VERIFIED FIXED
8 years ago
4 years ago

People

(Reporter: madhava, Assigned: mbrubeck)

Tracking

Fennec 1.1
x86
Mac OS X

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
When I start the browser and a tab other than the start page is shown (for example - a "you've updated page" from an add-on), the start page is zoomed in too much in its tab.  See the example here:

http://www.flickr.com/photos/madhava_work/4493967770/
(Reporter)

Updated

8 years ago
tracking-fennec: --- → ?
What steps did you do? We need to be able to reproduce this.
(Reporter)

Comment 2

8 years ago
I only see it on start-up when an add-on has its own start page, so that's what I see when the browser comes up.  Weave does this when it updates, and TwitterBar does it on installation, I think.  The start page is there in the first tab, but not visible on startup, because this other tab is selected instead.
(Reporter)

Comment 3

8 years ago
Also, in this state, doubletap zooming doesn't seem to do anything.
(Reporter)

Comment 4

8 years ago
When I flip to portrait, the portrait version lays out properly, and it's fixed in landscape when I rotate back to landscape.
(Assignee)

Updated

8 years ago
Assignee: nobody → mbrubeck
Status: NEW → ASSIGNED
(Assignee)

Comment 5

8 years ago
Created attachment 437612 [details] [diff] [review]
patch: updateDefaultZoom on selectedTab change

When about:home loads in the background, its tab's browserViewportState.viewPortRect is still the default (0,0,1,1).

This causes pageZoomLevel to return the maximum zoom level, because it is called by getZoomForPage with browserW: 1, browserH: 1.

The underlying cause for both this and bug 529089 is that BrowserView.updateDefaultZoom only handles the front tab, so MozScrolledAreaChanged events for background tabs are ignored.

The simplest fix is to call updateDefaultZoom from set selectedTab.  This does lead to some extraneous calls to updateDefaultZoom, but these are cheap when the zoom has not actually changed.  See the attached patch, which also fixes bug 529089.

If for some reason we don't want to do that, we could modify BrowserView to be able to zoom background tabs (fairly involved), or we could record when tabs have "pending" MozScrolledAreaChanged events that were ignored while in the background.
Attachment #437612 - Flags: review?(mark.finkle)
Comment on attachment 437612 [details] [diff] [review]
patch: updateDefaultZoom on selectedTab change

This patch does fix the problem.

I am worried about the amount of work we do when changing tabs. We should profile.
Attachment #437612 - Flags: review?(mark.finkle) → review+
pushed:
http://hg.mozilla.org/mobile-browser/rev/3f5066602cdb
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
verified FIXED on builds:

Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:1.9.2.4pre) Gecko/20100412 Namoroka/3.6.4pre Fennec/1.1a2pre

and

Mozilla/5.0 (X11; U; Linux armv6l; en-US; rv:1.9.3a4pre) Gecko/20100412 Namoroka/3.7a4pre Fennec/1.1a2pre
Status: RESOLVED → VERIFIED
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.