Closed Bug 268487 Opened 20 years ago Closed 19 years ago

Open Link in New Tab always opens a new "Untitled" tab

Categories

(Firefox :: Tabbed Browser, defect)

x86
Linux
defect
Not set
major

Tracking

()

RESOLVED INVALID

People

(Reporter: bugzilla-mozilla, Assigned: bugs)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20041108 Firefox/1.0RC2
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20041108 Firefox/1.0RC2

On Redhat Enterprise Linux 3/amd64 and Tru64 UNIX 5.1 (both native 64-bit
platforms), right-clicking on a link and selecting "Open Link in New Tab" always
opens a new "Untitled" tab. The URL is never loaded in the new tab.

I thought this was a duplicate of #265704 but this is from a fresh install of
1.0RC2 from *source*.

I don't see this problem on Solaris 7, 8/SPARC, HP-UX 11.00, 11i, IRIX 6.5,
Redhat Linux 7.1, 9, nor RHEL 2.1/x86, 3/x86.

Reproducible: Always
Steps to Reproduce:
1. Right-click on a link and select "Open Link in New Tab"
2.
3.

Actual Results:  
A new tab appears but not containing the URL of the link, rather an "Untitled"
tab appears
BTW, this is a GTK2-enabled build of Firefox 1.0RC2. No substantial difference
in how it is built across the platforms where tabbed browsing works as expected.
*** Bug 268616 has been marked as a duplicate of this bug. ***
This problem still occurs with Firefox 1.0.

I can also duplicate it on AIX 5.2 though AIX 5.1 works ok. The following
platforms work:
  Solaris 2.6-9/SPARC
  HP-UX 11.00, 11i
  AIX 5.1
  IRIX 6.5
  Redhat Linux 7.1, 9
  Redhat Enterprise Linux 2.1/x86, 3/x86

Rather than using our GTK2 libraries, I used those supplied by RH for RHEL
3/amd64 and RHEL 3/x86, built as follows:
  $ cd /opt/build/mozilla
  $ BUILD_OFFICIAL=1 MOZILLA_OFFICIAL=1 MOZ_PHOENIX=1 ./configure
--enable-default-toolkit=gtk2 --enable-crypto --disable-ldap --disable-mailnews
--disable-strip --enable-extensions=default,-irc,-venkman,-wallet
--disable-debug --enable-xft --disable-gnomevfs --enable-single-profile
--disable-profilesharing --disable-installer --enable-mathml --enable-jsd
--enable-xpctools --enable-oji --enable-xinerama --prefix=/tmp/firefox10
  $ BUILD_OFFICIAL=1 MOZILLA_OFFICIAL=1 MOZ_PHOENIX=1 make
  $ BUILD_OFFICIAL=1 MOZILLA_OFFICIAL=1 MOZ_PHOENIX=1 make install
A GTK1-based build produced the same result.
I don't have this problem with Mozilla Firefox 0.10.1 but have the problem
moving from it to .10RC, 1.0RC1, 1.0RC2, and Firefox 1.0. Both middle clicking
on a link and right-clicking and choosing Open in New Tab operations have this
problem. It is reproduceable. I went from 0.10.1 to .10RC and back to 0.10.1,
from 0.10.1 to RC1 to 0.10.1, from 0.10.1 to RC2 to 0.10.1, and from 0.10.1 to
1.0 to 0.10.1. In each case, moving to the higher version introduces the problem
and going back solves it. I am running Windows 2000 SP4 on an Intel Pentium 3
1.0B GHz processor. I use the Firefox.zip version for win32. The problem I
experience is as described by the author: trying to middle-click a link produces
a new "Untitled" tab.
In regards to my above post, I misspoke. The error does not occur with "Firefox
1.0PR.zip" but occurs with releases after that. Again, I'm using WinNT 5.00.2195
SP4 with a P3 1.0GHz processor.
Yes, you're right. I just rebuilt 0.10.1 (firefox-1.0PR-source.tar.bz2) on RHEL
3/amd64 and this bug is not present.
I am seeing this bug on SPARC Solaris 8, using the Sun contributed Firefox 1.0
build.
Same bug after updating from Pre-Release to 1.0. Didn't exist with PR. I'm using
Mandrake 10.0.
I am seeing this bug under FreeBSD 4.10-STABLE compiled from source via the
ports tree.

Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20041112 Firefox/1.0
I'm getting it on FreeBSD 4.5 after a build of Firefox 1.0 from ports.
This bug appears to have something to do with the old data in your profile. I
deleted my .mozilla directory to remove all old profile data. When I then
restarted Firefox, it worked fine. I was able to restore bookmarks.html,
formhistory.dat, history.dat and cookies.txt from a backup without reintroducing
the problem.
We see this bug with *no* ~/.mozilla directory present.
(In reply to comment #13)
> We see this bug with *no* ~/.mozilla directory present.

I concur. I removed my old .mozilla dir and started firefox, and the problem
disappeared.
(In reply to comment #14)
> (In reply to comment #13)
> > We see this bug with *no* ~/.mozilla directory present.
> 
> I concur. I removed my old .mozilla dir and started firefox, and the problem
> disappeared.

You mean "I do not concur" in reply to comment #13. If you remove ~/.mozilla and
"Open Link in New Tab" worked for you, then you're not seeing what I'm seeing.
(In reply to comment #12)
> This bug appears to have something to do with the old data in your profile. I
> deleted my .mozilla directory to remove all old profile data. When I then
> restarted Firefox, it worked fine. I was able to restore bookmarks.html,
> formhistory.dat, history.dat and cookies.txt from a backup without reintroducing
> the problem.

compreg.dat is the offending file in my case, for what it is worth, though as
"The Written Word" points out, something else seems to cause this problem as well.
I am also seeing this problem on a clean 1.0 source build on Linux x86_64, even
starting with no .mozilla.
We can remove AIX 5.2 from the non-working list. After upgrading to the v7
compiler and implementing the fix for PR275004, "Open Link in New Tab" works!
This bug appears on Windows XP (Version 5.1 SP1) even after deleting the profile.
I have the same problem.

Version: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050107
Firefox/1.0

Action: Right click on URL -> Open Link in New Tab
Result: Tab opens, title: "(Untitled)", without url, page doesn't load in it...
Same for Windows XP Home.  I have heard that browser.tabs.loadOnNewTab and
browser.windows.loadOnNewWindow were disabled in Firefox.  Unbelievable, if that
is true!  When opening a new window, you get your home page, and when starting
your new tab, you get no nothin'.  Silly!

I repectfully ask that these two functions be activated in Firefox without
undue delay, because I am sure that many, like me, have a search engine
(e.g., Google) as their home page and want that to open when clicking the
New Tab tab (sic!) or File - New Tab.

Hans Leander
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050512 Firefox/1.0.4
I'm also seeing this error whenever it tries to open a new tab:
Error: uncaught exception: [Exception... "Component returned failure code:
0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance]" 
nsresult: "0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE)"  location: "JS frame
:: chrome://global/content/bindings/tabbrowser.xml :: get_fastFind :: line 1517"
 data: no]
I'm not sure it's related, though.  Yes I deleted compreg.dat, and all of
.mozilla even.  If anyone has any suggestions for debugging this, I'd be glad to
help.
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050921 Firefox/1.0.7

On Mandriva Linux 2005LE x86_64 this version only opens blank tabs.
A version of Firefox that is generated with EXACTLY the same .spec for Mandriva
Linux 2005LE i586, works just fine; tabbed browsing; opening with middle mouse
button, opening thru the right mouse button menu, opening all bookmarks in tabs
all work. So I guess this is related to a coding error that rears it's ugly head
in stuff that's not ix86 ?
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

I'm no longer seeing this issue on 1.5b2.
Still seeing this, 1.5.0.1 out of CVS, Linux, amd64, Debian/stable (base system via amd64.debian.net APT repository).

Browser built with gcc-3.4.4, GTK2 build, clean install.
Note, the following appears in the JavaScript Console:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance]"  nsresult: "0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE)"  location: "JS frame :: chrome://global/content/bindings/tabbrowser.xml :: get_fastFind :: line 1815"  data: no]
I'd bet that anyone seeing this has a bad .mozconfig that's building the typeaheadfind extension, which will collide with the interface forked into toolkit as a core component.
You're right about the typeahed in .mozconfig.
Is that the reason for this?
Verified, commenting out:
ac_add_options --enable-extensions

And rebuilding makes tabs work correctly.
marking INVALlD,  this is a build config bug
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.