Under the preferances and under the theme manager, when you seleect a theme, you can press a button to go to the theme's website. If you select this either before or after you change themes, the browser behind the prefferance window goes to the correct page, but the window focus is moved to the browser window and the modal preferance window can't regain focus. the browser keeps running without crashing, but it can't take any messages like close, move or anything else except for a kill by using ctrl-alt-del

Confirming for Win95 build 2000062708. Can anyone confirm for a non Windows build?

this sounds similar, if not a dup of bug 43800...

...the main diff is that here the browser actually freezes. hurm. i couldn't repro this using 2000.06.27.08 on linux using the following steps (Jeff, lemme know if they differ from yours): 1. open Prefs dialog, select Themes. 2. select (highlight) the "classic" theme. 3. attempt to click the "Website" button. result: for me the button is greyed out, and doesn't "depress," ie respond to mouseclicks. also, the webpage doesn't load in the browser window. all i get is "SetPrefToCurrentPage()" in the console. 4. i don't apply the theme, but i'm still able to dismiss the Prefs dialog normally (either OK or Cancel).

Well this is a MS Windows only problem, dealing in how it handles two windows both requesting focus, and one was trying to hold it exclusivly while the other took it away. Both windows simply stop responding to user input.

When I got the bug, the buttons (emai, and website) for the modern theme were greyed out even before i tried to click them. they were always greyed out. when i highlight the clasic theme, the buttons are not greyed out, and when i click on the webpage button it depresses on left_mouse_button_down and raises on left_mouse_button_up. That causes the browser in the background to retrieve the webpage and the whole error. different from the linux 2000.06.27.08 tester

Mozilla doesn't actually freeze. Again, it's a modality problem -- the preferences dialog is modal, but when the button tries to load the website in a nonmodal window -- that instance of the browser -- which also happens to be the prefwindow's owner. The reason it looks like the browser has frozen is because when you click in the browser window, it tries to set focus back to the prefwindow (since it's modal), but when you click in the prefwindow, focus tries to go back to the browser. I don't know how to counter this (I've wondered for awhile what we're going to do with the "More Information" button in smart browsing). Opening the URL in a new window might work (and seems more sensical, so the user can remain on whatever page he/she was browsing), however you still won't be able to access the site until you close the prefs window in the other browser instance (this is a separate bug, that modal windows are app- modal rather than owner-modal). cc ben for ideas

btw, sairuh you can reproduce by clicking the modern theme first then clicking the website button.

Just an update: John Gable, who's with marketing, says in bug 44025 that the Email and Website buttons should be text. If by this he means the email address and website should just be displayed in plain text (which I'm not sure I agree with, but I asked him) then this bug would (logically) no longer exist.

adding pp kw since this is win32 only.

*** Bug 48278 has been marked as a duplicate of this bug. ***

nominating for beta3 to get onto the "we should fix this" radar.

*** Bug 47295 has been marked as a duplicate of this bug. ***

I have a fix to make the website open in a new window. Is that an acceptable solution?

as mentioned earlier, bug 44025 was fixed, and the 'website' button was removed as a result of it. marking invalid...

a-yup. vrfy.

*** Bug 51014 has been marked as a duplicate of this bug. ***

*** Bug 52145 has been marked as a duplicate of this bug. ***