Closed Bug 302281 Opened 15 years ago Closed 15 years ago

Open links from external applications always opens link in new window


(Firefox :: Tabbed Browser, defect)

Not set





(Reporter: ispiked, Assigned: mconnor)



(Keywords: regression)


(1 file)

I'm almost possitive this is a regression from mconnor's patch to bug 300733. It
regressed sometimes between the 2005-07-25-05 and 2005-07-26-05 builds, which
happens to be when the patch for bug 300733 was checked in.
WFM with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4)
Gecko/20050726 Firefox/1.0+, opening a link from Colloquy.
I put some dump()s into the patch that mconnor made to see what everything was
outputting. What kept happening was that the call made to
windowList.hasMoreElements() was always returning false for some reason, no
matter how many windows I had open. Then it would just result in navWin getting
set to null each time and opening a new window.

Gavin Sharp pointed out bug 156333 comment 0 for a possible explanation as to
why hasMoreElements() isn't working as expected.
Same problem for me:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050726 Firefox/1.0+
I see the same problem:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050727 Firefox/1.0+
Flags: blocking-aviary1.5?
looks like the z-order stuff is horked for unix, I'll have to #ifdef for unix.

Whether that means we should open in a popup like before, or use
newest-to-oldest in place of z-order, I haven't decided yet.  Trivial fix though.
Assignee: nobody → mconnor
Flags: blocking-aviary1.5? → blocking1.8b4+
I think we should just be able to fix the unix z-order stuff... the comment in
bug 156333 seems fairly spot-on.
Okay, so I banged my head agains the windowmediator wall, but I don't know that
code well.

This is an alternate patch that fixes this issue by implementing the following
behaviour on Linux.

If the most recent window is fully chromed, we use that.  In cases where the
most recent window is not a popup, this is fine.  If this fails, we get the
newest (not topmost) window that has visible toolbars, and uses that window. 
If you open A, open B, then switch back to A and get a popup, you'll get B
instead of A, but I think that's acceptable as a short-term fix, and still
better than the previous behaviour before this was regressed.
i'm currently experiencing this problem, where new windows are opened rather
than new tabs.  however, i've noticed that this behavior seems to have regressed
all the way back to bug 268928.  i'm not an experiened programmer, and likewise
know nothing about the code involved, but might there be a clue/connection there?

my config is as follows:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050805 Firefox/1.0+

Build platform

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 3.3.5 (Debian 1:3.3.5-13) 	-Wall -W -Wno-unused -Wpointer-arith
-Wcast-align -Wno-long-long -pedantic -pthread -pipe
c++ 	gcc version 3.3.5 (Debian 1:3.3.5-13) 	-fno-rtti -fno-exceptions -Wall
-Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic
-fshort-wchar -pthread -pipe -I/usr/X11R6/include

Configure arguments
--enable-official-branding --enable-application=browser --enable-optimize
--disable-debug --enable-toolkit=gtk2 --enable-xft --disable-tests 
Blocks: 268928
Whiteboard: [has patch][needs review bsmedberg]
Comment on attachment 191165 [details] [diff] [review]
alternate approach for Linux

So as I mentioned, I got lost in nsIWindowMediator, if you have more feedback
than the other day, feel free, otherwise I'll file a followup bug on fixing
this the right way for 1.9.
Attachment #191165 - Flags: review?(benjamin)
Comment on attachment 191165 [details] [diff] [review]
alternate approach for Linux

totally ick
Attachment #191165 - Flags: review?(benjamin) → review+
Comment on attachment 191165 [details] [diff] [review]
alternate approach for Linux

totally, dude
Attachment #191165 - Flags: approval1.8b4?
Whiteboard: [has patch][needs review bsmedberg] → [has patch][has review, needs approval]
Comment on attachment 191165 [details] [diff] [review]
alternate approach for Linux

Attachment #191165 - Flags: approval1.8b4? → approval1.8b4+
This is so evil.  I'll file a followup on the z-order stuff tomorrow.
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][has review, needs approval]
This appears to have regressed in the 2005-08-13-22-trunk nightly.
(In reply to comment #14)
> This appears to have regressed in the 2005-08-13-22-trunk nightly.

Are you sure? Nothing that should affect this was landed in that timeframe.
Could you maybe have been using the wrong build to test?
Sorry - my mistake, it does still work. The problem is that the tab preference
is reset to open links in a new window by the new version each time. This just
happened again when I started using 2005-08-14. Is this a bug or the intended
changing to a new window is odd, it is known that there's some weirdness
switching between 1.0.x and trunk, but that's not really fixable.
You need to log in before you can comment on or make changes to this bug.