878597 - Selecting another tab during restore startup switches back to previously selected tab

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Brian Nicholson (:bnicholson)]

STR:
1) Load wikipedia.org and google.com as two separate tabs and select google.com tab
2) Minimize Fennec and make it be killed in the background (either by opening several apps or using oom-fennec)
3) Reopen Fennec
4) Immediately select wikipedia.org tab before anything loads

Following these steps, the browser starts to switch to wikipedia.org, but google.com is immediately re-selected.

Comment 1

[Brian Nicholson (:bnicholson)]

gkwong and MattN mentioned this annoyance today. I thought it was fixed awhile ago, but apparently not!

Comment 2

[Brian Nicholson (:bnicholson)]

Attachment: Don't propagate tab stub selection state in Tab:Added

What's happening:

1) Restore logic in Java is sending a Tab:Load message to Gecko with a selected flag
2) User selects a different tab while Gecko is still loading
3) Gecko finishes loading and Tab:Added is sent back to Java with the same selected flag
4) User's selected tab gets overridden

By the time Tab:Added comes back with the same selection, that selection may be stale. There's no reason to propagate the selection back to Java; since the tabs we're restoring are stubs, we've already selected them before receiving Tab:Added.

Comment 3

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

Comment on attachment 8344959 [details] [diff] [review]
Don't propagate tab stub selection state in Tab:Added

Instead of not sending the selected flag back to Java, could we not send it at all from Java in the first place?

Comment 4

[Brian Nicholson (:bnicholson)]

(In reply to Mark Finkle (:mfinkle) from comment #3)
> Comment on attachment 8344959 [details] [diff] [review]
> Don't propagate tab stub selection state in Tab:Added
> 
> Instead of not sending the selected flag back to Java, could we not send it
> at all from Java in the first place?

How would Gecko know to select the tab? Send a separate Tab:Select message after Tab:Load?

Comment 5

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

(In reply to Brian Nicholson (:bnicholson) from comment #4)
> (In reply to Mark Finkle (:mfinkle) from comment #3)
> > Comment on attachment 8344959 [details] [diff] [review]
> > Don't propagate tab stub selection state in Tab:Added
> > 
> > Instead of not sending the selected flag back to Java, could we not send it
> > at all from Java in the first place?
> 
> How would Gecko know to select the tab? Send a separate Tab:Select message
> after Tab:Load?

OK, I should read more of the code. I am getting mixed up.

Only thinking about the "stub" case now. Java sends the "it's a stub" param to Gecko, but Java also sends a "select this tab" param to Gecko. When Gecko makes the stubbed tab, it sends a Tab:Added message to Java, but since this is a stub we tell Java to not select the tab,even if the "selected" param is true.

If what I said is true, then why not just always send "selected: false" when sending a stub tab message to Gecko?

Comment 6

[Brian Nicholson (:bnicholson)]

Attachment: Don't propagate tab stub selection state in Tab:Added, v2

Moves the check into Java instead as discussed over IRC.

Comment 7

[Brian Nicholson (:bnicholson)]

https://hg.mozilla.org/integration/fx-team/rev/0491b6ab227d

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/0491b6ab227d