Closed
Bug 177946
Opened 22 years ago
Closed 22 years ago
opentabfor.windowopen does not open new tab
Categories
(Firefox :: General, defect)
Tracking
()
VERIFIED
INVALID
People
(Reporter: Bugzilla-alanjstrBugs, Assigned: bugzilla)
Details
Attachments
(1 file)
439 bytes,
text/html
|
Details |
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.
Comment 2•22 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.
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.
Comment 6•22 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); 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.
Comment 8•22 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).
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.
Comment 10•22 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.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Comment 11•21 years ago
|
||
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.
Reporter | ||
Comment 12•21 years ago
|
||
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."
You need to log in
before you can comment on or make changes to this bug.
Description
•