This comes as a report from an actual user using an actual web app, not a synthetic testcase. BUILD: Current trunk STEPS TO REPRODUCE: 1) Create a new browser window with a single tab. 2) Open the attached testcase in that tab. 3) Click the link. Observe the text in the new tab. 4) Switch back to the tab the testcase is loaded in. 5) Click the link again a few times. Note that the label of the tab that was opened in step 3 keeps changing as new text is loaded in that tab. 6) Open Panorama. 7) Put the tab with the testcase and the tab opened in step 3 in separate tab groups. 8) Close panorama, such that the tab the testcase is in is the one you see. 9) Click the link. EXPECTED RESULTS: Open a new tab as in step 3. ACTUAL RESULTS: Load happens in the tab that's in a background tab group; no user feedback on the click. MORE INFORMATION: The simplest thing to do here is probably to mark the tabs in non-visible tabgroups as not targetable (change type from "content-targetable" to "content"). The main drawback is that if some script in such a non-visible tab runs and tries to do a load that targets another non-visible tab then it won't find its target and we'll end up opening a new tab for it (presumably in the invisible tab group, but still). Or trigger the popup blocker and fail the load, or something. A perhaps better solution, but one that involves backend work, is to make tabs in a tab group only able to target other tabs in the same tab group. This can break sites, though, if they hold on to references to windows and try to load things in them by name and access the DOM via their window reference... Perhaps when a window is targeted (and perhaps focus() is called) it should move to the tab group it was targeted from? Note that targeting only works same-origin. Another possibility is to give some sort of feedback that the load was in a background tab plus the option to switch to it (akin to what the awesomebar does now already). Not sure whether that would need string changes, though.... Thoughts?
I wouldn't really call our no-panorama behaviour particularly useful in terms of "feedback" - the tab title change is rather subtle and hard to notice unless you're looking for it. Chrome selects the targeted tab in that case, which is much more obvious. I'd be interested in finding out more about the actual web app that was affected by this, because it seems to me like a pretty minor edge case...
OS: Mac OS X → Windows 7
> I'd be interested in finding out more about the actual web app that was > affected by this I believe it was the web frontend to MS Exchange, but can double-check. It's quite possible that the app in question makes a focus() call somewhere in there too. The testcase is just what I wrote up from a verbal description of the observed problem. I can get more details about what the non-panorama behavior looks like on the actual web app if desired.
OK, double checked. This is an online homework management system: http://www.coursecompass.com/ The non-panorama behavior is in fact suboptimal, but at least it's something. You get the throbber, etc. Improving it might still be worth it. ;)
bugspam. Moving b10 to b11
bugspam. Removing b10
No longer blocks: 608028
Punting to post Fx4
No longer blocks: 627096
Target Milestone: --- → Future
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 587466
This has nothing to do with bug 587466. Or more precisely, there are better solutions here than bug 587466.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Panorama has been removed from Firefox 45, currently in Beta and scheduled for release on March 7th. As such, I'm closing all existing Panorama bugs. If you are still using Panorama, you will see a deprecation message in Firefox 44, and when 45 is released your tab group data will be migrated to bookmarks, with a folder for each group. There are also a few addons offering similar functionality. See https://support.mozilla.org/en-US/kb/tab-groups-removal for more info. We're removing Panorama because it has extremely low usage (about 0.01% of users), and has a large number of bugs and usability issues. The cost of fixing all those issues is far too high to justify, and so we'll instead be focusing our time and energy on improving other parts of Firefox.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago → 3 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.