795833 - Loading page in background does not update the SurfaceView

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Andreea Pod]

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

Comment 1

[Aaron Train [:aaronmt]]

Nice find. Is this a regression?

I was able to reproduce on a Nexus 7, Nightly (10/01).

Comment 2

[Aaron Train [:aaronmt]]

A rotation of the device paints the appropriate content.

Comment 3

[Andreea Pod]

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.

Comment 4

[Brad Lassey [:blassey] (use needinfo?)]

Chris, sounds like an invalidation bug

Comment 5

[Chris Lord [:cwiiis]]

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

Comment 6

[Andreea Pod]

Last good build is 20120928040137:
http://hg.mozilla.org/integration/mozilla-inbound/rev/9f476b4ac1e1

First bad build is 20120928042236:
http://hg.mozilla.org/integration/mozilla-inbound/rev/6b58397ad735

http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9f476b4ac1e1&tochange=6b58397ad735

Comment 7

[Chris Lord [:cwiiis]]

Indeed, regression caused by DLBI.

Comment 9

[Aaron Train [:aaronmt]]

Other STR in Brian's bug, bug 799783 comment #0

Comment 10

[Brad Lassey [:blassey] (use needinfo?)]

Chris, how's your investigation on this coming?

Comment 11

[Chris Lord [:cwiiis]]

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.

Comment 12

[Brian Nicholson (:bnicholson)]

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

[Paul Feher]

This is still reproducible using my Samsung Galaxy R (Android 2.3.4) using latest Nightly 19.0a1 (2012-11-19).

Comment 14

[Kartikaya Gupta (email:[e-mail])]

(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.

Comment 15

[Brian Nicholson (:bnicholson)]

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.

Comment 17

[Brad Lassey [:blassey] (use needinfo?)]

Matt, Chris is off and we're tracking this for 18. Can you have a look?

Comment 18

[Matt Woodrow (:mattwoodrow)]

Sure, I'll have a look at this on Monday.

Comment 19

[Matt Woodrow (:mattwoodrow)]

Attachment: Fix the RedrawAll method

Comment 20

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9c63294d0a87

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9c63294d0a87

Comment 22

[Ioana Chiorean]

(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.

Comment 23

[Ioana Chiorean]

It was Firefox 20.0a1 (2012-11-19)

Comment 24

[Mark Finkle (:mfinkle) (use needinfo?)]

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?

Comment 25

[Alex Keybl [:akeybl]]

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.

Comment 26

[Brian Nicholson (:bnicholson)]

(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.

Comment 27

[Alex Keybl [:akeybl]]

(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 28

[Matt Woodrow (:mattwoodrow)]

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

Comment 29

[bhavana bajaj [:bajaj]]

Comment on attachment 693227 [details] [diff] [review]
Fix the RedrawAll method

Approving on beta/aurora as it is low risk .

Comment 30

[Matt Woodrow (:mattwoodrow)]

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.