Closed Bug 302281 Opened 15 years ago Closed 15 years ago
Open links from external applications always opens link in new window
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+
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 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
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 a=shaver
Attachment #191165 - Flags: approval1.8b4? → approval1.8b4+
This is so evil. I'll file a followup on the z-order stuff tomorrow.
Status: NEW → RESOLVED
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 behavior?
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.