The default bug view has changed. See this FAQ.

Parts of long pages stay on low-res tiles forever

VERIFIED FIXED

Status

()

Firefox for Android
General
VERIFIED FIXED
5 years ago
8 months ago

People

(Reporter: samth, Assigned: cwiiis)

Tracking

15 Branch
ARM
Android
Points:
---

Firefox Tracking Flags

(firefox14 fixed, firefox15 fixed, blocking-fennec1.0 beta+)

Details

(Whiteboard: [mozilla-central])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Sometimes, if I scroll down on a large page while it's loading, I eventually reach low-resolution tiles, and they never get converted to high-res tiles, unless I reload the page.  

This happened before the switch to low-resolution tiles -- previously it was just displayed as all-black.

Unfortunately, I can't make this happen reliably, but it most often happens when all three of the following are the case:

1. I'm on a slow network (ie, 3G).
2. I scroll down quickly on a very long page.
3. I double-tap to zoom before the page finishes loading.

Updated

5 years ago
blocking-fennec1.0: --- → ?

Updated

5 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 1

5 years ago
I saw this happening the other day, but also have no solid way of reproducing... It seems to happen more often after restoring fennec from the background, but that may just be coincidence.
Keywords: qawanted

Updated

5 years ago
Duplicate of this bug: 751838
I've seen this too. Happens a lot on forum pages. Didn't get around to filing yet.

Happened to me on a Transformer tablet on wifi, so it doesn't seem to be much to do with speed.
Browsing around http://ftp.mozilla.org seems to cause this to happen.
Keywords: qawanted
Chris can you look into this?
Assignee: nobody → chrislord.net
blocking-fennec1.0: ? → +
Attempted to repro, but couldn't. Dammit, Fennec, you're too fast!
blocking-fennec1.0: + → ?
blocking-fennec1.0: ? → beta+
(Assignee)

Comment 7

5 years ago
I'm having a hard(/impossible) time reproducing this. If anyone has reliable, or even semi-reliable STR, please list them.

Comment 8

5 years ago
I've described a similar behavior in the Bug 751838 which was duplicated after this one. Maybe the STR posted there will help.
I was able to reproduce this on gmail (basic HTML site, not the mobile one) after pinch zooming. I just retested today using a nightly and I can't reproduce it anymore.
You wont see this on Nightly because low res is busted: bug 752910.
(In reply to Aaron Train [:aaronmt] from comment #10)
> You wont see this on Nightly because low res is busted: bug 752910.

OK. I tested in Aurora, using 2012-05-07 and I see this issue on GMail. Use the desktop site. I can't pan around. Pinch zoom in a decent amount. Now I can pan around and when I do the page can go low-res and not go high-res.
(Assignee)

Comment 12

5 years ago
Ok, after poking at the lifecycle code for bug 752910, I've found solid STR for any page page.

1- Load a page.
2- Press the awesome-bar to bring up the awesome-screen
3- Press the home button
4- Load the browser again

You will now be in a state where the compositor will not redraw anything - you'll still see the old rendered content, retained tiles and the low-res cache, but no tiles will get updated.

This seems to be due to the stop/start events in GeckoApp, and what happens when isApplicationInBackground is true. Due to what I assume is a work-around, isApplicationInBackground only ever returns false when an activity has been launched (such as the awesome-screen).

I'll take a look at this tomorrow.
Blocks: 752910
Take a glance at bug 752368 and maybe try the patch there -- it could be related, though the symptoms are different (I get just a black content area when the content/compositor gets wedged, not old content).  But it could be related.
Yeah, different than bug 752368; ignore that.  I can reproduce it in my build with those patches applied.  I also noticed that once it's in the state after the STR from comment #12, I can navigate to a new page and get its content rendered... but zooming in/panning/etc. doesn't update any tiles beyond that.
Duplicate of this bug: 753003
Created attachment 622171 [details] [diff] [review]
Patch

This puts a static variable in GeckoApplication, which knows whether the application was sent to background or not. Every activity relies on that static variable to ascertain if the application is in background or not.

Note: isApplicationSentToBackground() is not intended to be used by any activity. It will be used by GeckoApplication to see whether it is in foreground or not.
Attachment #622171 - Flags: review?(mark.finkle)
Comment on attachment 622171 [details] [diff] [review]
Patch

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

::: mobile/android/base/GeckoActivity.java.in
@@ +69,2 @@
>      public boolean isApplicationInBackground() {
> +        return GeckoApplication.isApplicationInBackground();

Why is this static, when the rest of this file uses ((GeckoApplication) getApplication()).foo() ?

::: mobile/android/base/GeckoApplication.java
@@ +10,5 @@
>  import android.app.Application;
>  
>  public class GeckoApplication extends Application {
>  
> +    private static boolean mInBackground = false;

Kill the `static`. Otherwise you're just going to have to fix this later (e.g., for Bug 753102).

(And isn't m* the warped-Hungarian for "member"? If this is static, it should be sInBackground.)
Attachment #622171 - Flags: feedback+
Comment on attachment 622171 [details] [diff] [review]
Patch

r+ but I agree about dropping the static stuff
Attachment #622171 - Flags: review?(mark.finkle) → review+
Created attachment 622205 [details] [diff] [review]
Patch

This patch removes the "static" member.

I felt "isApplicationSentToBackground()" will still be a misnomer for anyone trying to use on the activity. Hence I used "isGeckoActivityOpened()" which reflects the actual state of the variable.
Attachment #622171 - Attachment is obsolete: true
Attachment #622205 - Flags: review?(mark.finkle)
Is this patch causing the crashes you told me about on IRC?
(In reply to Mark Finkle (:mfinkle) from comment #20)
> Is this patch causing the crashes you told me about on IRC?

<sriram> i tried removing the "static" 
<sriram> but it crashes the app
<sriram> like.. WINDEATH
<sriram> with no exception

So maybe we should try to use the original patch, which uses the "static" bits for now.

Chris - Can you try that patch out when you get a chance?
(Assignee)

Comment 22

5 years ago
(In reply to Mark Finkle (:mfinkle) from comment #21)
> (In reply to Mark Finkle (:mfinkle) from comment #20)
> > Is this patch causing the crashes you told me about on IRC?
> 
> <sriram> i tried removing the "static" 
> <sriram> but it crashes the app
> <sriram> like.. WINDEATH
> <sriram> with no exception
> 
> So maybe we should try to use the original patch, which uses the "static"
> bits for now.
> 
> Chris - Can you try that patch out when you get a chance?

Patch seems to work for me, can't easily duplicate the issue in comment #12 anymore.
Attachment #622205 - Flags: review?(mark.finkle) → review+
https://hg.mozilla.org/mozilla-central/rev/be5203774846
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Whiteboard: [mozilla-central]
Comment on attachment 622205 [details] [diff] [review]
Patch

[Triage Comment]
Attachment #622205 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/9bd737acd13f
status-firefox14: --- → fixed
status-firefox15: --- → fixed
Verified on Galaxy S II; 5/11 Nightly.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.