Closed Bug 177946 Opened 22 years ago Closed 22 years ago

opentabfor.windowopen does not open new tab

Categories

(Firefox :: General, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

VERIFIED INVALID

People

(Reporter: Bugzilla-alanjstrBugs, Assigned: bugzilla)

Details

Attachments

(1 file)

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 window.open's create a new tab does not work. 
Instead, nothing new opens.
Attached file Test cases
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.
I have Tabbed Browsing Extensions installed, which gives a checkbox for this option.
The two tests are the same in terms of options.  The only difference is that one
is wrapped in a void().
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.
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);
see http://texturizer.net/phoenix/tips.html#lay_marquee

user_pref("middlemouse.paste", true);


Alan;

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.
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.
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).
With tab extensions disabled, I get a pop-up windows (Pheonix resolves
http://localhost to www.localhost.com, 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.  
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. 
Status: UNCONFIRMED → RESOLVED
Closed: 22 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.
Any extensions that are hosted on MozDev get their own Bugzilla
(bugzilla.mozdev.org).  Extensions hosted elsewhere are responsible for their
own bug tracking.  As Asa said "bugzilla is not the place to report bugs in
extensions."
v.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.