313055 - Need a way for windows to say "don't open links from other applications in THIS window" (e.g. for popup windows)

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect)

Description

[dolphinling]

If I have Firefox set to open links from other applications in a new tab, and
have a small javascript popup open, then click a link in another application, it
will open in a new tab in that small window, which is not what I want.

Windows should have some way to say "don't open a new tab from an outside
application in me". If the first window firefox would open the tab in says this,
it should try another. If all open windows say this, it should open a new window.

I would suggest making this default for windows opened with no url bar (or
attempted so, if the user has dom.disable_window_open_feature.location=true set).

I have no idea if authors should be able to affect this; if so, it's for another
bug as it would have to be decided exactly how to expose it.

Comment 1

[Jesse Ruderman]

See also bug 243893 (already fixed).

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Isn't this a dupe of 243893? Am I misinterpreting something? Using the latest
nightly (Gecko/20051020 Firefox/1.5) I tried the following:

  - opened my blog (http://www.beltzner.ca/mike)
  - opened a popup by viewing comments (opens with window.open(width=..,height=..)
  - clicked on a link from other app (tried Tbird and MS Word)
  - tab opens in the fully chromed browser, not the popup

Comment 3

[dolphinling]

I can't understand the code well enough to be sure, but it looks like what bug
243893 did was check if a window has a navigation bar and if not, don't open in
that window. That fails if the user has dom.disable_window_open_feature.toolbar
= true.

I suppose one of three things could happen: 

1) That bug could be reopened and this bug duped to it
2) This bug could be changed to "do a better job checking"
3) This bug could stay as "add something new to windows" and when it's fixed
   change that bug to use the new mechanism.

I don't really like 1, as it requires somewhat morphing a fixed bug. I don't
know if 2 is possible at all. In any case, 3 seems more elegant to me, but I
don't know what if any problems it would cause.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Ah, OK, I understand you now.

Also, fwiw, I think options 2 and 3 are essentially the same. The desire is that
we "do a better job checking" and this particular bug suggests a way to do that
(requesting that windows get tagged as "tabbable" or "non-tabbable" based on how
they were opened by javascript).

Comment 5

[Mike Connor [:mconnor]]

hmm, I'm not overly concerned with the case where someone disables hiding
toolbars, but not scrollbars, to be perfectly honest.  These are both hidden
prefs that are best used together.

Comment 6

[Boris Zbarsky [:bzbarsky]]

This is really an app issue, not a core tabbrowser issue...

Comment 7

[Bryan]

I run into this very annoying bug every time I use Java based chat.  I use a service that has a java based sidebar that has links to my email and such.  Ever since the consolidation of the tab prefs., the links I click on in the sidebar now open as tabs in the sidebar!!!  This is very annoying as the sidebar isn't or wasn't meant for tabs.  The links should open in a new tab in a existing or new window and not the sidebar.  This sidebar has no FF menu bars.  It's just HTML generated.

Can we either fix this or revert the existing behavior for the tab prefs back?

~B

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Can you provide a testcase, please, Bryan?

Comment 9

[dolphinling]

This works now: links from other apps won't open in windows opened from window.open, but will open in the most recently used window opened with ctrl-n. No idea what fixed it.

Comment 10

[Jesse Ruderman]

Fixed by bug 377551, maybe?