I found a cool new way to screw things up in phoenix. 1. Choose Help/About (a dialog box appears, well done) 2. Click on the link in the dialog (copyright etc) The weirdness begins: it opens a new phoenix window with the about: info but the window doesn't appear in the task bar. The window seems fully operational, I'm able to click on links and write new addresses in the url bar. Now, let's shake things up some more: 1. Open a new window (just to see it doesn't appear in the task bar either) 2. Press ctrl-f (find dialog appears, dismiss with esc) 3. Press ctrl-f again Find dialog doesn't work any more. Manage bookmarks works every other time. About doesn't work. After closing some windows (they minimize in a weird Windows 3.1-like manner, btw) you can see that the about dialog is still blocking the first window. Clicking ok makes things normal again: newly opened windows appear in the task bar and the find dialog etc. work.
Joonas, thanks for the bug. Blake, is this anything we can fix? Can we just target the original window for loading that content?
Just a little addition to this bug: The new window that's spawned when clicking on the link in the about box is apparently a modal window, just like the about box, so it becomes impossible to switch from the new window to any other Phoenix window until the new window is closed. I'm not sure if this behavior is the same under Linux, but in Windows it's certainly annoying.
I don't know about the iconisation side of things in WMs with task bars, since it all works well enough in fvwm 2.4 (well, other than that download windows - not the download manager! - are uniconisable and unshrinkable, but that's a different bug), but the browser window created from the About dbox is modal, as is any browser window created from that (at least via ^N). Maybe the About dialogue box shouldn't be modal? :-)
This affects windows and linux.
OS: Windows XP → All
*** Bug 172246 has been marked as a duplicate of this bug. ***
Forgot to say this in the initial report: the about dialog should close before loading new content. Doing that would probably fix this bug.
*** Bug 173883 has been marked as a duplicate of this bug. ***
*** Bug 177793 has been marked as a duplicate of this bug. ***
A related oddity: Let's say that while I'm filling out this "Additional Comments" box, I want to paste in the exact build/version of Phoenix that I'm using. So I go to Help/About, then click on the Copyright & Contributors link. I highlight the UA string and press Ctrl-C to copy it to the Windows clipboard. I close that window with Ctl-W, and then press Escape to close the About box. Now this "Additional Comments" text box has focus again. But most normal cursor movements don't work, and if I press Ctl-V to paste my UA string, it fails. I click outside the text box, press F7 a few times to toggle the "caret" mode on and off, and then I click back into the text box. Now things are back to normal and I can paste the UA: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3a) Gecko/20021119 Phoenix/0.4
I had a similar problem, except after I go to help/about and copyright info etc... In the new window that is spawned I am unable to follow any bookmarks OR type anything in the address bar. After I close both that window and the about dialogue, I am able to go to bookmarks from the original window, however they are opened in a new and different window. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021231 Phoenix/0.5 This is still a problem. I've only ever programmed in Visual Basic, so I can't check this for myself in the code. Or maybe I could if I even knew where to start looking! But isn't this just a matter of setting a flag on the API call to create a new window, i.e. setting it as a normal window instead of a modal one? 'Cause this is a pretty annoying bug, it would be nice to see it closed.
how about opening that copyright document in the about dialog itself? I have written a simple proof-of-concepte patch.
the patch which tries to use a different mechanism to display copyright information, fixing this bug.
*** Bug 197548 has been marked as a duplicate of this bug. ***
*** Bug 202758 has been marked as a duplicate of this bug. ***
*** Bug 202757 has been marked as a duplicate of this bug. ***
Does "Get New Extentions" also cause this? Just something to check. I'm on Linux, where all it causes is the prefs to get stuck open.
*** Bug 206340 has been marked as a duplicate of this bug. ***
Why not just get rid of the dialog box? Mozilla doesn't have it (and doesn't need it, IMO). It doesn't seem to add anything to the overall product, and all the info that is there is also on the "about:" page (which is what Mozilla opens when clicking Help->About).
When you open the Help, About Mozilla Firebird page and press the "Copyright and Contributor information" link, a new page open. If you minimize this new window, it becomes impossible to press "ok" or to anything in the "about mozilla firebird" dialog. Only after closing the new window does it again become possible to use the "old" browser window again. This is under Linux. Seems to be the same as mentioned under MS Windows in comment #2.
*** Bug 214028 has been marked as a duplicate of this bug. ***
*** Bug 217688 has been marked as a duplicate of this bug. ***
*** Bug 217899 has been marked as a duplicate of this bug. ***
*** Bug 217933 has been marked as a duplicate of this bug. ***
uses a copy of visitLink from pref.xul to properly open a new window with the appropriate link.
Attachment #116538 - Attachment is obsolete: true
Comment on attachment 131005 [details] [diff] [review] use the same function as links in Options dialogs works in the same fashion as "Get New Extensions" etc. The other option is to define an actual dialog with an iframe, but that's probably more than needed.
Assignee: blake → mpconnor
Priority: -- → P3
Target Milestone: Firebird1.0 → Firebird0.8
This bug also exists in the Mac OS X version of Firebird. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6a) Gecko/20031003 Firebird/0.7+/jtalkington-nightly Not the task bar issue, obviously (and everything seems to work fine on the dock). But the blocked second "find" problem in subsequent windows, and the inability to close the dialog box if the copyright window is minimized (or in the foreground, it seems) are pretty much as described for the Windows versions here.
Comment on attachment 131005 [details] [diff] [review] use the same function as links in Options dialogs Thanks for pointing this out.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Thanks noririty. I can confirm this *mostly* fixed on Mac build 20031020 Firebird/0.7+ However I don't think the bug should be marked as fixed yet. There are still two weird issues. So far I've only checked the Mac build, not a PC one. 1. When you bring up the "About Mozilla Firebird" box and then click "Copyright and contributor information", it brings up the info window, but immediately foregrounds your current window, so the info window is hidden behind it. If you blinked at the wrong moment you'd never know it was there. It should stay in the foreground. 2. If you have two browser windows open. Bring up the "about" info using window 1. Leave it open, but foreground window 2. Then minimize window 2. Close the "about" info associated with window 1. Maximize window 2 again. You'll notice that the address bar in window 2 is unresponsive, amongst other things. If you background window 2, then foreground it again, the problem goes away. If you have even more windows open, and minimize them all, then even stranger patterns of window problems occur. In fact, if you minimize, say, 3 browser windows, it's possible to maximize them again and see the bug on one of them without even closing the "about" info first. It becomes messy at this point. But I'm hoping the simple pattern is enough to go on to locate the problem.
Windows version works fine. 20031021 Firebird/0.7+
verified fixed 20031027
Status: RESOLVED → VERIFIED
*** Bug 228065 has been marked as a duplicate of this bug. ***
*** Bug 232703 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.