808290 - browser.link.open_newwindow=1 is unpredictable when a link is clicked immediately before focusing a new tab

Status: UNCONFIRMED

(Firefox :: Tabbed Browser, defect)

Description

[Stephan Sokolow]

When browser.link.open_newwindow is set to 1 (force all target="" and window.open() to remain in the current tab), "current" is resolved to be "the tab with focus at the time the HTTP request begins" rather than "the tab in which the link was clicked".

On browsers where some combinations of leaky extensions, lots of open tabs, etc. bog down the garbage collector, there's often a 0.5-1.0 second delay between a link being clicked and the throbber appearing, during which an experienced user may switch tabs.

That means that, when I'm operating on muscle memory, I click a link, switch tabs, and then curse and reach for the Back button as the contents of the tab I just arrived on are replaced... possibly risking unsaved form data in the process.

This is surprisingly common since I often middle-click links in batches (eg. in gallery sites) and then alternate between clicking something like "full view" and switching to the next tab.

Given how typical it is to see this kind of thing done by mistake when programming asynchronously using callbacks (forgot to capture all relevant state when the initial event was fired), I seriously doubt it's an intentional feature.

Furthermore, given how much it grinds my workflow to a halt just as I'm getting into the flow of things (and how it requires me to make heavy use of the Back button), I'd say this is as big a problem to users who have enabled this feature as was Firefox 2's tendency to miss keystrokes when under heavy load.

(In case anyone doesn't remember, if Firefox 2 was really bogged down (which it usually was on Linux) and you typed "google.com" in the address bar, you might end up with "gool.om". Firefox 3 fixed that.)

Comment 1

[Ioana (away)]

Stephan, can you please attach a reduced testcase that reproduces this bug?

Comment 2

[Stephan Sokolow]

I don't understand Firefox internals enough.

How would I induce browser lag between clicking a link and having the throbber appear via a plain old HTML file? ...or is there a way to write privileged testcases that I'm unaware of?

Comment 3

[Ioana (away)]

(In reply to Stephan Sokolow from comment #2)
> I don't understand Firefox internals enough.
> 
> How would I induce browser lag between clicking a link and having the
> throbber appear via a plain old HTML file? ...or is there a way to write
> privileged testcases that I'm unaware of?

I was thinking of a test case where you catch the event of clicking on the link and make it wait until it actually opens the link. Of course, that might be difficult to implement.

Another option would be to attach to this bug (or email me) your profile, so I reproduce the bug with it and confirm it.

Comment 4

[Stephan Sokolow]

(In reply to Ioana Budnar [QA] from comment #3)
> (In reply to Stephan Sokolow from comment #2)
> > I don't understand Firefox internals enough.
> > 
> > How would I induce browser lag between clicking a link and having the
> > throbber appear via a plain old HTML file? ...or is there a way to write
> > privileged testcases that I'm unaware of?
> 
> I was thinking of a test case where you catch the event of clicking on the
> link and make it wait until it actually opens the link. Of course, that
> might be difficult to implement.
> 
> Another option would be to attach to this bug (or email me) your profile, so
> I reproduce the bug with it and confirm it.

Given that I've go something like 900 loaded-on-demand tabs in tab groups I only touch infrequently plus countless bookmarks, I'm not sure I want to share my profile.

Also, this isn't the sort of thing that just happens immediately when you fire up my profile. I have to wait a week or two for the addons to leak the memory usage up to the 3-4GiB range so the garbage collector will slow things down enough to induce said lag.

I could try writing that test case, but I don't see how it would test what I'm talking about.

If anything, the behaviour I've encountered would need a testcase which induces a middle-click and then forces a tab focus change quickly enough that it happens before the throbber gets set up. (And I don't know how to write privilieged test cases, nor do I have any experience with Firefox's internal API)