opentabfor.windowopen does not open new tab




16 years ago
16 years ago


(Reporter: alanjstr, Assigned: Blake Ross)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021101 Phoenix/0.4

user_pref("browser.tabs.opentabfor.windowopen", true);

Setting it so that javascript's create a new tab does not work. 
Instead, nothing new opens.

Comment 1

16 years ago
Created attachment 104884 [details]
Test cases

Comment 2

16 years ago
Linux 20021101

The user_pref is having no effect at all here; the test cases continue to pop up
even with the user_pref implemented. In fact, none of my Javascript preferences
seem to be having any effect as I have one set to prevent hiding the status bar
yet the test case's 2nd link does just that.

Comment 3

16 years ago
I have Tabbed Browsing Extensions installed, which gives a checkbox for this option.

Comment 4

16 years ago
The two tests are the same in terms of options.  The only difference is that one
is wrapped in a void().

Comment 5

16 years ago
Is this really a bug in Phoenix? Isn't that pref something that the Tabbed
Browsing Extensions introduce?

Regarding #2, the statusbar is not hidden here until after I install Tabbed
Browsing Extensions.

Comment 6

16 years ago
Ok, scratch my earlier remarks in comment #2. The status bar is being displayed
always now, but I also updated to a newer build as well.

I didn't have Tabbed Extensions installed earlier but now that I have pop up
windows are shunted into new tabs.

Nevertheless, the original problem still exists.

Re comment #5 - Phoenix should obey all user preferences in user.js and it
doesn't; this may be a more generalized problem with Phoenix and user.js. I can
think of a few others that have no effect as well.

user_pref("browser.display.enable_marquee", false);

user_pref("middlemouse.paste", true);


by 'nothing new' do you mean you get no pop-up or tab at all, or that it
continues to do what it did before (no effect).

There's obviously something going on here but I can't confirm anything as we all
seem to be getting slightly different results.

Comment 7

16 years ago
Allan, what happens if you click on those links with just Phoenix installed,
i.e. no extensions?

Regarding comment #6, if this pref indeed is handled by Tabbed Browsing
Extensions (can someone confirm this?), then you can't expect that Phoenix will
make use of it just because it is there. Simply adding it to user.js will then
do as much good on a plain Phoenix install as adding
"user_pref("mozgest.navigator", true);" will do.

Comment 8

16 years ago
Please, keep ONE issue in this bug, not a whole bunch. The marquee bug is
completely unrelated (the code for that pref was backed up in bug 161109).

Comment 9

16 years ago
With tab extensions disabled, I get a pop-up windows (Pheonix resolves
http://localhost to, blech; time for an entry in hosts).  

With a new profile, tab extensions enabled, and just that line in user.js, I get
a pop up window that opens, then a split second later turns into a tab.  Now
_that_ was freaky.

Ok, so this 'feature' is enabled by Tab Extensions.  What confused me was that
it does not show up as browser.tabs.extensions.opentabfor.windowopen.  I don't
have Mozilla, so I don't know if this is in Moz but not Phoenix.  

I'll see if browser.tabs.extensions.only_one_window accomplishes the same
functionality that I'm looking for.

My problem was that not only was there no pop-up window, there was no tab either.

If this is truly a extensions only item (despite the preference name), then I
can go pester its creator.  

Comment 10

16 years ago
bugzilla is not the place to report bugs in extensions. And if you're setting
mozilla preferences in Phoenix and expecting them to all work, don't. 
Last Resolved: 16 years ago
Resolution: --- → INVALID
Perhaps Bugzilla could be a place to report bugs in Mozilla Extensions.

1) Some extension bugs will be reported here, albeit primarily by users who
don't know any better (and so, probably write poor bug reports).

2) It would make it easier to identify and group extension-related bugs because
the most common extension bugs would already be in the system, easy to triage as
"Duplicate," rather than the triaging member having to be aware of the
extensions problems.

3) "Extensions" could be added to the list of "Products" and a "Component" could
be added for each extension Bugzilla ends up taking bugs for. The primary
contact for all such bugs could be the developer of the extension.

It isn't the Mozilla team's responsibility to allow for such piggy-backing, but
it would be a very community-friendly thing to do, and it may be best case for
both the Extension writers and the Moz team.

Comment 12

16 years ago
Any extensions that are hosted on MozDev get their own Bugzilla
(  Extensions hosted elsewhere are responsible for their
own bug tracking.  As Asa said "bugzilla is not the place to report bugs in

Comment 13

16 years ago
You need to log in before you can comment on or make changes to this bug.