Closed
Bug 302281
Opened 19 years ago
Closed 19 years ago
Open links from external applications always opens link in new window
Categories
(Firefox :: Tabbed Browser, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: ispiked, Assigned: mconnor)
References
Details
(Keywords: regression)
Attachments
(1 file)
1.89 KB,
patch
|
benjamin
:
review+
cbeard
:
approval1.8b4+
|
Details | Diff | Splinter Review |
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.
Comment 1•19 years ago
|
||
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.
Reporter | ||
Comment 2•19 years ago
|
||
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.
Comment 3•19 years ago
|
||
Same problem for me: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050726 Firefox/1.0+
Comment 4•19 years ago
|
||
I see the same problem: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050727 Firefox/1.0+
Updated•19 years ago
|
Flags: blocking-aviary1.5?
Assignee | ||
Comment 5•19 years ago
|
||
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+
Comment 6•19 years ago
|
||
I think we should just be able to fix the unix z-order stuff... the comment in bug 156333 seems fairly spot-on.
Assignee | ||
Comment 7•19 years ago
|
||
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 target i686-pc-linux-gnu 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
Assignee | ||
Updated•19 years ago
|
Whiteboard: [has patch][needs review bsmedberg]
Assignee | ||
Comment 9•19 years ago
|
||
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 10•19 years ago
|
||
Comment on attachment 191165 [details] [diff] [review] alternate approach for Linux totally ick
Attachment #191165 -
Flags: review?(benjamin) → review+
Assignee | ||
Comment 11•19 years ago
|
||
Comment on attachment 191165 [details] [diff] [review] alternate approach for Linux totally, dude
Attachment #191165 -
Flags: approval1.8b4?
Assignee | ||
Updated•19 years ago
|
Whiteboard: [has patch][needs review bsmedberg] → [has patch][has review, needs approval]
Comment 12•19 years ago
|
||
Comment on attachment 191165 [details] [diff] [review] alternate approach for Linux a=shaver
Attachment #191165 -
Flags: approval1.8b4? → approval1.8b4+
Assignee | ||
Comment 13•19 years ago
|
||
This is so evil. I'll file a followup on the z-order stuff tomorrow.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][has review, needs approval]
Comment 14•19 years ago
|
||
This appears to have regressed in the 2005-08-13-22-trunk nightly.
Comment 15•19 years ago
|
||
(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?
Comment 16•19 years ago
|
||
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 behavior?
Assignee | ||
Comment 17•19 years ago
|
||
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.
Description
•