Loading page in background does not update the SurfaceView

VERIFIED FIXED in Firefox 19

Status

()

VERIFIED FIXED
6 years ago
2 years ago

People

(Reporter: andreea.pod, Assigned: mattwoodrow)

Tracking

18 Branch
Firefox 20
ARM
Android
Points:
---

Firefox Tracking Flags

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

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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: --- → ?
status-firefox18: --- → affected
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.
(Reporter)

Comment 3

6 years ago
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.

Updated

6 years ago
Keywords: regressionwindow-wanted
Chris, sounds like an invalidation bug
Assignee: nobody → chrislord.net
tracking-fennec: ? → 18+

Comment 5

6 years ago
I suspect bug 539356 going on the date and the symptoms. A more accurate regression range would be good though.

Comment 7

6 years ago
Indeed, regression caused by DLBI.
Blocks: 539356
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?

Comment 13

6 years ago
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
Duplicate of this bug: 816034
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)
(Assignee)

Comment 18

6 years ago
Sure, I'll have a look at this on Monday.
Flags: needinfo?(matt.woodrow)
(Assignee)

Comment 19

6 years ago
Created attachment 693227 [details] [diff] [review]
Fix the RedrawAll method
Attachment #693227 - Flags: review?(roc)
https://hg.mozilla.org/mozilla-central/rev/9c63294d0a87
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 20

Comment 22

6 years ago
(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
status-firefox19: --- → affected
status-firefox20: --- → verified

Comment 23

6 years ago
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?
tracking-firefox18: --- → ?
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.
status-firefox18: affected → wontfix
tracking-firefox18: ? → -
tracking-firefox19: --- → +
(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.
(Assignee)

Comment 28

6 years ago
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+
(Assignee)

Comment 30

6 years ago
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+

Updated

6 years ago
status-firefox19: affected → fixed
You need to log in before you can comment on or make changes to this bug.