1081560 - Opening recent tab from awesomescreen with kbd closed results in blank page

Status: RESOLVED INVALID

(Firefox for Android Graveyard :: General, defect)

Description

[Mark Capella [:capella]]

I can open a recent tab if I have a new tab openned to about:home, then swipe (or tap) to "RECENT TABS" Panel, and tap a listitem. I wind up with two openned tabs, the original about:home, and the requested recent tab.

If from the now openned recent tab I tap the awesome bar, then tap the "RECENT TABS" Panel, and tap another recent listitem, I wind up looking at a blank screen.

fyi- https://www.dropbox.com/s/5hqkq2g764ftkgf/bugRecentBlank.png?dl=0

Openning the tabstray, I see that the second tab is still the selected one (expected) it's just blank. Tapping on the 3d/recent tab I openned last, switches to it and displays it ok. Tapping back to the 2d (again via the tabstray) clears up the blank screen / displays it properly.

Also fyi, I seem to see this in the current version of Aurora after I build it. The beta version that I build seems unaffected.

Comment 1

[:Margaret Leibovic]

Sadly this is bug 732752. I've been meaning to get around to it, but haven't found time. Hopefully soon! Or you can also take a stab at it if you like :)

Comment 2

[:Margaret Leibovic]

(In reply to Mark Capella [:capella] from comment #0)
> I can open a recent tab if I have a new tab openned to about:home, then
> swipe (or tap) to "RECENT TABS" Panel, and tap a listitem. I wind up with
> two openned tabs, the original about:home, and the requested recent tab.

Actually this is bug 732752.

> If from the now openned recent tab I tap the awesome bar, then tap the
> "RECENT TABS" Panel, and tap another recent listitem, I wind up looking at a
> blank screen.
> 
> fyi- https://www.dropbox.com/s/5hqkq2g764ftkgf/bugRecentBlank.png?dl=0
> 
> Openning the tabstray, I see that the second tab is still the selected one
> (expected) it's just blank. Tapping on the 3d/recent tab I openned last,
> switches to it and displays it ok. Tapping back to the 2d (again via the
> tabstray) clears up the blank screen / displays it properly.
> 
> Also fyi, I seem to see this in the current version of Aurora after I build
> it. The beta version that I build seems unaffected.

But this sounds like something different.

Can you get a regression range?

Comment 3

[Mark Capella [:capella]]

Yah, I spent some time yesterday tracking this ... bisecting. Then I realized I can't repro on my N7, only on my SG3 which has CM11-snapshot-M10 / 4.4.4 ...

I can repro using a combination of http://arstechnica.com/ as my first "recent tab", and some (but not all) other articles in Ars for my second "recent tab". 

This one repros consistently.
http://arstechnica.com/gadgets/2014/10/i-let-yondr-lock-my-smartphone-in-a-sock-so-i-could-live-in-the-moment/

I'll redo the bisect testing and let you know if I find anything.

It's annoying as I use my GS3 regularly, and I'm surprised no-one else has noticed, so maybe cm11 is complicating things.

Comment 4

[Mark Capella [:capella]]

Ok, while I was bisecting the root cause of this bug on my SG3, I tinkered around with my N7 and was also able to intermittently repro it there, so cm11 seems not to be a factor.

Testing on my SG3, with slightly complex, but repeatable steps ...

The last good revision I have:

   changeset:   195144:462bb749420e
   date:        Mon Jun 09 16:48:01 2014 +1200
   Bug 1022612. Part 16: No need to exclude final transparent region from window opaque region. r=mattwoodrow

      What it looks like ................
      https://www.dropbox.com/s/e73029ay12wi7ht/bug1081560Good.mp4?dl=0

The next / first bad revision where I can faithfully repro is:

   changeset:   195145:c15aca574567
   date:        Wed Jun 11 23:12:14 2014 +1200
   Bug 1022612. Part 17: RecordFrameMetrics should not set layer visible regions. r=mattwoodrow

      What it looks like ................
      https://www.dropbox.com/s/5r44p0wg3ies6xo/bug1081560Bad.mp4?dl=0

Comment 5

[:Margaret Leibovic]

Sounds like a regression from bug 1022612 then. roc, any ideas about what could be going wrong?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Not off the top of my head, but I presume it's my bug.

Comment 7

[James Willcox (:snorp) ([e-mail]) (he/him)]

:roc are you working on this?

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It's on my list but I've got a bug backlog.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm a bit stumped. I can reproduce the bug on my phone but we don't seem to do a layer transaction when you press on one of the "recent tabs" and the current tab shows up black. The compositor tree looks OK too. In fact we don't seem to do any composition when switching tabs as far as I can tell. So it's hard to tell why my changes would make a difference.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That comment is probably wrong.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We are compositing when we switch tabs, but I can't figure out why we draw black. The layer tree dumps all look fine. Based on the regressing patch, the obvious guess is that we fail to set a visible region on some layer, but all the visible regions look fine. I don't know how to debug this further.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Maybe I'm doing it wrong but I built 462bb749420e and I still see the bug in that revision. These are my steps to reproduce:
1) Start Fennec. http://arstechnica.com/ was the only tab open after I closed it last time, so that automatically loads.
2) When it's nearly finished loading I tap the X in the URL bar because it takes too long to fully load.
3) Tap the URL bar to bring up the Fennec homescreen.
4) Swipe across to "recent tabs"
5) Tap on "HTML5 specification finalized", an article I previously loaded, under "Recently closed tabs".
6) We switch back to the Ars Technica tab, and it's black for a few seconds, after which (with no further interaction) the content reappears.
7) If I press the "squares" icon in the top right and swipe away the new loading tab, I can then resume at step 3 and reproduce the bug again as many times as I want.

This reproduces 100% on my Nexus S running Android 4.1.2. That is the bug this bug is about, right?

Mark, can you reproduce with 462bb749420e with those steps?

Comment 13

[Mark Capella [:capella]]

ugh ... yes I can ... it looks like I mis-identified the source of the issue. The fact that you can repro it makes me feel better, I've been confused why no one else has noticed this other than triggering it seems flakey/flukey.

I can also see it (for example) using a combination of pages starting on HackerNews, so it doesn't look site-specific.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Are you going to look for a new regression range or am I?

Comment 15

[Mark Capella [:capella]]

I'll stay with it - thanks  :-)

Comment 16

[Mark Capella [:capella]]

To be clear ... the bug isn't step 6 above where it's blank for a few seconds then the content re-appears in the current tab while the requested recent tab loads in the background ...

What I see is that after we snap back to the current tab and the content is blank, it stalls that way and never re-displays without further UI interaction.

For example, if we then open the tray, tap / switch to rerecent tab we requested to be openned, it appears, and then tap switching back to the original

Comment 17

[Mark Capella [:capella]]

(con't) ... and then switching back to the original "current" tab, in your example arstechnica, resumes proper display.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Isn't step 6 being blank for a few seconds a bug?

Comment 19

[Mark Capella [:capella]]

Well I'd say yes :)

But I see the sluggish thing almost all the way back to the original patch at various times ... the hard hang has been the easier target to bisect towards.

Comment 20

[Mark Capella [:capella]]

Morphing the description ... caught a new wrinkle while trying to tighten the STR (wondering why my bisecting was producing inconsistent results).

I can repro in nightly, on various sites (arstechnica, hackernews, washington post, the guardian), on my tablet and my phone, using various keyboards (google, swiftkey).

Correct behaviour:
   1) Open a URL in the first tab
   2) Tap the awesome bar
   3) Tap a listitem from the RECENT TABS panel /while the keyboard is open/
      (RECENT TABS is already my selected about:home panel)
   4) The keyboard will close
   5) The original content in the first tab will reappear
   6) The listitem is opened in a second tab in the background

The error occurs at step 3) ... if I have to navigate to the RECENT TABS panel via UI swipe or by tapping the RECENT TABS panel tab:

   -) The keyboard will be dismissed
   -) Tap a listitem from the RECENT TABS panel /while the keyboard is closed/
   -) The original content in the first tab will /not/ reappear
   -) We appear to stall with a blank page displayed

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Mark Capella [:capella] from comment #19)
> But I see the sluggish thing almost all the way back to the original patch
> at various times ...

What do you mean "the original patch"?

My guess is that the this bug is the same as the older bug, but sometimes something makes the content reappear and that's happens less now.

I have a feeling that the older bug has something to do with Android UI or painting code which I don't know much about.

Comment 22

[:Margaret Leibovic]

capella, are you looking for a new regression range? We're currently tracking this for 34 because we thought it was a regression there, but we should re-nom this if it's a regression elsewhere.

Comment 23

[Mark Capella [:capella]]

Yes, it's regressed as detailed in comment #20 for Beta-34.

I've been re-miss for the last week, and haven't gotten back to bisecting this. I'm looking now.

Comment 24

[Mark Capella [:capella]]

Well, using my refined STR I'm still seeing the behaviour introduced with changeset 195145:c15aca574567 as originally mentioned. (Originally I saw mixed results/success in reproducing and I'm sorry for any confusion there.)

In any case, this seems to be a little-noticed issue, and I'm happy to let it go, or re-nom, unless or until I can have it confirmed.

Comment 25

[Mark Capella [:capella]]

I can't repro this any longer ... not an issue.