613701 - Link target handling fairly broken with Panorama

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Panorama, defect, P4)

Description

[Boris Zbarsky [:bzbarsky]]

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?

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

Comment 2

[:Gavin Sharp [email: [e-mail]]]

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...

Comment 3

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.  ;)

Comment 5

[Kevin Hanes]

bugspam. Moving b10 to b11

Comment 6

[Kevin Hanes]

bugspam. Removing b10

Comment 7

[Ian Gilman [:iangilman]]

Punting to post Fx4

Comment 9

[Boris Zbarsky [:bzbarsky]]

This has nothing to do with bug 587466.  Or more precisely, there are better solutions here than bug 587466.

Comment 10

[Justin Dolske [:Dolske]]

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.