Apps can be size incorrectly, ignoring the viewport rules

RESOLVED FIXED in Firefox 28

Status

()

Core
Panning and Zooming
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: vingtetun, Assigned: vingtetun)

Tracking

Trunk
mozilla28
Points:
---

Firefox Tracking Flags

(firefox28 fixed)

Details

Attachments

(2 attachments)

I have seen that a few times by opening the Galery app with APZ turned on (i don't have a SD card in this device). The app seems zoomed out, like if the <meta viewport> info has not been taken into account.

One step to reproduce is:
 - Open the sms app
 - Click on the 'New Message' button
 - Click on the 'Add attachment' button
 - In the activity selector, click the galery app

Expected result:
 - The gallery app opens with the right size

Actual result:
 - The gallery app opens like if there is no meta viewport.

Note: There is no SD card in this phone.
Actually it seems like there is a race somewhere. I can reproduce the issue just by opening the gallery app directly from the homescreen. But it does not happens all the time.

So I found a nicer way to reproduce this for all apps:
 - Click on the homescreen to open the application of your choice
 - Very quickly hit home after the previous step
 - wait a little bit
 - Click on the app icon again (Note that sometime you have to hit home again otherwise nothing happens when you click on the homescreen, sounds like a Gaia bug).

Expected result:
 - the application correctly sized

Actual result:
 - The application is wrongly sized, taking only a small part of the screen
Component: Gaia::Gallery → Panning and Zooming
Product: Firefox OS → Core
Summary: The gallery app is not size correctly when opened as an activity from an other app → Apps can be size incorrectly, ignoring the viewport rules
Duplicate of this bug: 944511
Created attachment 8341073 [details] [diff] [review]
bug943831.wip.patch

Seems like a regression from bug 943831. kats do you have any idea it we really need to return early if there is no scroll identifiers ?

So basically if the application is launched and then quickly hidden, we never set the viewport correctly.
Attachment #8341073 - Flags: feedback?(bugmail.mozilla)
Comment on attachment 8341073 [details] [diff] [review]
bug943831.wip.patch

Review of attachment 8341073 [details] [diff] [review]:
-----------------------------------------------------------------

I'm fine with doing this. I would have expected HandlePossibleViewportChange() to get called again when the app is brought to the foreground which would have made this moot. I guess it doesn't really need to be though.
Attachment #8341073 - Flags: feedback?(bugmail.mozilla) → feedback+
Comment on attachment 8341073 [details] [diff] [review]
bug943831.wip.patch

Then let's ask r? since I don't know what else I can do here...
Attachment #8341073 - Flags: review?(bugmail.mozilla)
Comment on attachment 8341073 [details] [diff] [review]
bug943831.wip.patch

Review of attachment 8341073 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/ipc/TabChild.cpp
@@ +533,5 @@
>    uint32_t presShellId;
>    ViewID viewId;
> +  if (APZCCallbackHelper::GetScrollIdentifiers(document->GetDocumentElement(),
> +                                               &presShellId, &viewId)) {
> +   SendUpdateZoomConstraints(presShellId,

Fix indent
Attachment #8341073 - Flags: review?(bugmail.mozilla) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/30a98b93ba25
Assignee: nobody → 21
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla28
Version: unspecified → Trunk
Created attachment 8342554 [details]
2013-12-04-14-36-51.png

Another way to reproduce this is:
0. turn on APZ in settings
1. make sure camera and gallery are not launched
2. launch camera
3. select gallery

Not sure if this should be a separate bug?
I guess the only way to find out is to apply the patch.
I noticed some other strange behaviors with not properly resizing when changing orientations as well.
https://hg.mozilla.org/mozilla-central/rev/30a98b93ba25
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Blocks: 949585
No longer blocks: 949585
Does this only apply to Firefox OS platforms?
status-firefox28: --- → fixed
You need to log in before you can comment on or make changes to this bug.