Loading page in background does not update the SurfaceView

VERIFIED FIXED in Firefox 19

Status

()

defect
VERIFIED FIXED
7 years ago
3 years ago

People

(Reporter: andreea.pod, Assigned: mattwoodrow)

Tracking

18 Branch
Firefox 20
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox18- wontfix, firefox19+ fixed, firefox20 verified, fennec18+)

Details

Attachments

(1 attachment)

Build: Firefox 18.0a1 (2012-09-30)
Device: Samsung Galaxy Nexus
OS: Android 4.1.1

Steps to reprduce:
1. Open two or more different tabs (no about: pages)
2. Go to settings and Clear private date (all options are checked)
3. Return to main window and open that tab menu
4. switch to another tab

Expected result:
- the tabs should switch and loaded page content should display. 

Actual result:
- the address bar switches to the chosen tab but the content area does not display the page loaded in that tab
Nice find. Is this a regression?

I was able to reproduce on a Nexus 7, Nightly (10/01).
tracking-fennec: --- → ?
Summary: Switching tabs after Clear private data does not update the page area → Switching tabs after clearing private data does not update content in the viewport; mismatch between visible URL
A rotation of the device paints the appropriate content.
While I was looking for a regression range I noticed that this happens only after update. So the first build on witch is reproducible is the build from 2012-09-29 but only if you had the 28/09's build or older and you installed over it the 29/09's build.
Chris, sounds like an invalidation bug
Assignee: nobody → chrislord.net
tracking-fennec: ? → 18+
I suspect bug 539356 going on the date and the symptoms. A more accurate regression range would be good though.
Indeed, regression caused by DLBI.
Blocks: dlbi
Duplicate of this bug: 799783
Other STR in Brian's bug, bug 799783 comment #0
Chris, how's your investigation on this coming?
Flags: needinfo?(chrislord.net)
I can no longer reproduce this on current central, I guess this is fixed already?

Adding qawanted to confirm fix and if the fix isn't in Fx18, to get a range on when this issue was fixed in 19.
Flags: needinfo?(chrislord.net)
Keywords: qawanted
I'm still able to reproduce using both sets of STR in https://bugzilla.mozilla.org/show_bug.cgi?id=799783#c0. Easiest way to reproduce is to choose "Open in New Tab" from the AwesomeScreen, then wait a few seconds before closing the AwesomeScreen.

I added some logging, and it looks like setFirstPaintViewport() is never called when a page is loaded in the background, even after it has been brought to the foreground. Is that expected?
This is still reproducible using my Samsung Galaxy R (Android 2.3.4) using latest Nightly 19.0a1 (2012-11-19).
Keywords: qawanted
(In reply to Brian Nicholson (:bnicholson) from comment #12)
> I added some logging, and it looks like setFirstPaintViewport() is never
> called when a page is loaded in the background, even after it has been
> brought to the foreground. Is that expected?

As far as I remember this is not the expected behaviour. It should get called when it is brought to the foreground.
Here's a test page with easier STR:
1) Go to http://people.mozilla.com/~bnicholson/test/red.html
2) Put the activity in the background somehow (click the home button or open the AwesomeScreen)
3) Wait 5 seconds
4) Go back to the activity

You should see the title "Green" with a green background. Instead, you see the title "Green" with a red background. If you click the tabs button in the top right corner, the page's thumbnail is green, so there's a mismatch between what Gecko thinks is being displayed and what's actually drawn.

Updating the title of this bug since this is much more general than just clearing private data.
Summary: Switching tabs after clearing private data does not update content in the viewport; mismatch between visible URL → Loading page in background does not update the SurfaceView
Matt, Chris is off and we're tracking this for 18. Can you have a look?
Assignee: chrislord.net → matt.woodrow
Flags: needinfo?(matt.woodrow)
Sure, I'll have a look at this on Monday.
Flags: needinfo?(matt.woodrow)
Attachment #693227 - Flags: review?(roc)
https://hg.mozilla.org/mozilla-central/rev/9c63294d0a87
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 20
(In reply to Brian Nicholson (:bnicholson) from comment #15)
> Here's a test page with easier STR:
> 1) Go to http://people.mozilla.com/~bnicholson/test/red.html
> 2) Put the activity in the background somehow (click the home button or open
> the AwesomeScreen)
> 3) Wait 5 seconds
> 4) Go back to the activity
> 
> You should see the title "Green" with a green background. 

Using the STR from Brian's comment and the ones from the description I am no longer able to reproduce this on :
Firefox 20.0a1 (2012-11-18)
Device: Galaxy Nexus
OS: Android 4.1.1

Marking bug as VERIFIED FIXED.
Status: RESOLVED → VERIFIED
It was Firefox 20.0a1 (2012-11-19)
The fix looks small, but is it low-risk enough to try for an 18.0.1 since both 18 and 19 are affected (based on the flags). Also, should this be uplifted to Aurora too?
If this only happens when one clears private data, I don't think we should take any code change for this issue. The user impact here is fairly small.
(In reply to Alex Keybl [:akeybl] from comment #25)
> If this only happens when one clears private data, I don't think we should
> take any code change for this issue. The user impact here is fairly small.

That's not the only way to reproduce this; see https://bugzilla.mozilla.org/show_bug.cgi?id=799783#c0 and https://bugzilla.mozilla.org/show_bug.cgi?id=795833#c15 for other STR. In general, it happens any time a page loads when Fennec isn't in the foreground.
(In reply to Brian Nicholson (:bnicholson) from comment #26)
> That's not the only way to reproduce this; see
> https://bugzilla.mozilla.org/show_bug.cgi?id=799783#c0 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=795833#c15 for other STR. In
> general, it happens any time a page loads when Fennec isn't in the
> foreground.

Thanks Brian. Still doesn't seem critical enough to cause us to spin a mobile 18.0.1. Please nominate for uplift to Aurora/Beta as soon as possible.
Comment on attachment 693227 [details] [diff] [review]
Fix the RedrawAll method

[Approval Request Comment]
Bug caused by (feature/regressing bug #): DLBI
User impact if declined: Rendering not updated when resuming application
Testing completed (on m-c, etc.): Been on m-c for a few weeks
Risk to taking this patch (and alternatives if risky): Very low risk
String or UUID changes made by this patch: None
Attachment #693227 - Flags: approval-mozilla-beta?
Attachment #693227 - Flags: approval-mozilla-aurora?
Comment on attachment 693227 [details] [diff] [review]
Fix the RedrawAll method

Approving on beta/aurora as it is low risk .
Attachment #693227 - Flags: approval-mozilla-beta?
Attachment #693227 - Flags: approval-mozilla-beta+
Attachment #693227 - Flags: approval-mozilla-aurora?
Attachment #693227 - Flags: approval-mozilla-aurora+
Comment on attachment 693227 [details] [diff] [review]
Fix the RedrawAll method

https://hg.mozilla.org/releases/mozilla-beta/rev/465507610dab

This is actually already on aurora.
Attachment #693227 - Flags: approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.