Component: Tabbed Browser → DOM
Product: Firefox → Core
QA Contact: tabbed.browser → general
This was not always the way it behaved. It seems to have been doing the expected behavior in 2.0(.0.0), and changed to the observed behavior at 22.214.171.124
I don't see quite the behavior comment 0 describes on trunk, and I don't know what would have changed from 2.0 to 126.96.36.199 to affect this (other than perhaps UI code). But it would indeed be nice to improve the sorting of nsXULWindow::mTargetableShells. Right now any time a tab is switched to or from it gets moved to the end of the list, basically. Looking at the UI code, the pattern is to first set the tab being switched away from as content-targetable, then to set the tab being switched to as content-primary. Which means that it might make sense to put a newly-added entry at the start (instead of the end) of the list if one of two things holds: 1) It's primary 2) There is no primary (since that means it presumably just stopped being primary).
Status: UNCONFIRMED → NEW
Component: DOM → XP Miscellany
Ever confirmed: true
QA Contact: general → brendan
In fact, that approach guarantees that when opening a tab in the background it'll get added at the end, and that when switching tabs the list will end up with the new tab first, then the tab being switched away from, then all other tabs. In other words, we maintain the invariant that the currently-selected tab is the first entry in the list. When changing tabs, we first take the first entry out the the list, then put it back as the first entry, then move some other entry to the front. Therefore the entries are always listed in "most recently focused first" order. Doing the other suggestions from comment 0 would actually be a good bit more work, for questionable benefit.
Created attachment 292195 [details] [diff] [review] Something like this jst, what do you think about the branch prospects here? My first instinct is to not mess with the branch...
11 years ago
Summary: Named windows/tabs are randomly targeted from windows that target them → [FIX]Named windows/tabs are randomly targeted from windows that target them
Target Milestone: --- → mozilla1.9 M11
Comment on attachment 292195 [details] [diff] [review] Something like this r+sr=jst. Doesn't seem like a big issue, so I wouldn't worry about this on the branch.
Comment on attachment 292195 [details] [diff] [review] Something like this Requesting 1.9 approval. This changes the ordering of the targetable frames array, so we select a slightly saner target when we have multiple targets with the same name. Only changes the ordering, so the worst regression risk is that the targets we select won't be as good as the ones we select now. I don't foresee that happening.
Attachment #292195 - Flags: approval1.9?
Comment on attachment 292195 [details] [diff] [review] Something like this bz thanks for the explanation..
Attachment #292195 - Flags: approval1.9? → approval1.9+
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.