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

RESOLVED FIXED in Firefox 29

Status

()

Firefox for Android
General
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: bnicholson, Assigned: bnicholson)

Tracking

({reproducible})

Trunk
Firefox 29
All
Android
reproducible
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

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

Updated

5 years ago
Keywords: reproducible
(Assignee)

Comment 1

4 years ago
gkwong and MattN mentioned this annoyance today. I thought it was fixed awhile ago, but apparently not!
Assignee: nobody → bnicholson
Status: NEW → ASSIGNED
(Assignee)

Comment 2

4 years ago
Created attachment 8344959 [details] [diff] [review]
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.
Attachment #8344959 - Flags: review?(mark.finkle)
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?
(Assignee)

Comment 4

4 years ago
(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?
(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?
(Assignee)

Comment 6

4 years ago
Created attachment 8345122 [details] [diff] [review]
Don't propagate tab stub selection state in Tab:Added, v2

Moves the check into Java instead as discussed over IRC.
Attachment #8344959 - Attachment is obsolete: true
Attachment #8344959 - Flags: review?(mark.finkle)
Attachment #8345122 - Flags: review?(mark.finkle)
Attachment #8345122 - Flags: review?(mark.finkle) → review+
https://hg.mozilla.org/mozilla-central/rev/0491b6ab227d
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
You need to log in before you can comment on or make changes to this bug.