Closed
Bug 271914
Opened 20 years ago
Closed 20 years ago
-remote openFILE() does not honour opening pages in a new tab
Categories
(Firefox :: Tabbed Browser, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 280636
People
(Reporter: doj, Assigned: bugs)
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 If you invoke new pages with the -remote feature from the command line on Linux, Firefox 1.0 does not honour the user settings from the "Preferences" Dialog when "new-tab" is choosen and the webpage is loaded from harddisk via openFile(). In Contrast openURL() is working correctly. Reproducible: Always Steps to Reproduce: 1. Choose Preferences -> Advanced -> Tabbed Browsing -> a new tab in the most recent window 2. from the command line issue this command 'firefox -remote "openURL(http://yahoo.com)"'. yahoo will load in a new tab 3. issue this: 'firefox -remote "openURL(http://google.com)"' and google will load in a new tab. Thus the new-tab setting works with the openURL() command 4. issue: 'firefox -remote "openFILE(/etc/passwd)"'. The google page (if it was still active) is now used to display your passwords, but they should show up in a new tab leaving the google tab intact. Actual Results: The last tab is loaded with the contents of the file. Expected Results: The file contents should be shown in a new tab.
Comment 1•20 years ago
|
||
Take a look at the bugs at: https://bugzilla.mozilla.org/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=new+tab+remote&product=Firefox&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= and see if this one is a duplicate of any of those.
Reporter | ||
Comment 2•20 years ago
|
||
(In reply to comment #1) No, those are all not dealing with the interaction of openURL() and openFILE(). (However somebody with write access to the mozilla.org webpages should definitely write an updated version of the whole "-remote" options, because those changed two times between 0.8,0.9 and 1.0 releases and people are by now totally confused how to make it work, because when they look up solutions in the archives they don't work anymore.)
I may have a similar problem: firefox -remote openFile"(/etc/passwd,new-tab)" fails to open anything while firefox -remote openFile"(/etc/passwd,new-window)" always successfully opens a new window. PS: I'm running: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Comment 4•20 years ago
|
||
Is this related to bug 267435? For me, "openURL(http://google.com)" works like it is supposed to (new tab, as per setting in preferences), but "openURL(http://google.com)" loads it in current tab, like the problem with openFILE described here, which I also have.
Comment 5•20 years ago
|
||
Sorry, I meant openURL(google.com), without a protocol, opens in the current tab, replacing what is there.
Reporter | ||
Comment 6•20 years ago
|
||
Erik's comment gave me a hint for a workaround. If you want to open the file in a new tab you have to prefix the filename with "file:". My Firefox now behaves correctly if I issue a command like "openFILE(file:/etc/passwd,new-tab)". So this is really a bug, that when the argument to openURL or openFILE is not prefixed with a protocol (http,ftp,file or whatever) Mozilla/Firefox ignores any new-tab settings and always opens in the current tab. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=280636">bug 280636</a> has fixes to the firefox start script which will fix the described behaviour as well. I have thus marked this bug a a duplicate of that bug. *** This bug has been marked as a duplicate of 280636 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•