Closed
Bug 236467
Opened 21 years ago
Closed 21 years ago
Moz. 1.7x Pref Panel fails to display properly and can only be accessed once per Suite launch.
Categories
(SeaMonkey :: Preferences, defect)
SeaMonkey
Preferences
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: gcgjr, Unassigned)
References
Details
(Keywords: regression, Whiteboard: See Attachment # 143418 & Comment #32.)
Attachments
(6 files)
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040304
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040304
Preference Panel can be accessed only once per launch of Moz. Suite 1.7x. If a
second attempt to access the panel is made w/i the same session, panel is not
displayed and behaves as a "no-op" or nil condition, i.e. no action. Pref.
panel, when displayed is milling entries in its left pane. Left Pane is blank.
This condition does not occur in Moz. 1.6.
Reproducible: Always
Steps to Reproduce:
1. Launch Moz. 1.7x
2. Click on "Preferences" in "Mozilla" drop-down menu in toolbar.
3. Preference Panel will display with its left pane blank.
4. Click "OK" and panel closes.
5. Repeat step #2. Panel will not be displayed.
Actual Results:
1. Flawed Preference Panel is displayed once.
2. Panel will not display a second time.
Expected Results:
Moz. Suite should properly display its Preference Panel as many times as
required by the user in the same session, w/o relaunching.
This condition may be unique to the Mac OSX version of Mos. Suite 1.7x
I confirmed this bug on MacOSX10.2.8(BuildID of Mozilla-trunk: 2004030405).
I'll take screenshot. I'll create a attachment.
Reporter | ||
Comment 3•21 years ago
|
||
Moz. 1.7x Pref Panel fails to display properly.
It did not reproduce.
Mac OS X 10.3.2
Used New Profile
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040305
Comment 5•21 years ago
|
||
I did a build (updated from CVS) at 2PM EST and I'm still seeing it.
Comment 6•21 years ago
|
||
*** Bug 236698 has been marked as a duplicate of this bug. ***
Comment 7•21 years ago
|
||
->all from dup bug 236698 (linux)
worksforme linux seamonkey 2004-02-26-09-trunk, also with new profile
worksforme linux seamonkey 2004-03-06-10-trunk, also with new profile
OS: MacOS X → All
Hardware: Macintosh → All
Updated•21 years ago
|
Comment 8•21 years ago
|
||
*** Bug 236691 has been marked as a duplicate of this bug. ***
Comment 9•21 years ago
|
||
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:) Gecko/20040306
I´m using the default (classic) theme
Comment 10•21 years ago
|
||
I can reproduce it on Windows Server 2003, MozJF's build - Mozilla/5.0 (Windows;
U; Windows NT 5.2; en-US; rv:1.7b) Gecko/20040306
Comment 11•21 years ago
|
||
In reply to Bug 228904 comment 10:
This bug is reported against v1.7x ... but only v1.6 (working) and v1.7b (buggy)
are mentionned:
Could someone who is seeing the bug test and report about v1.7a ?
A possible workaround, copied from bug 236691 comment 5:
{{
Deleting XUL.mfasl works for me too.
}}
Could those who are seeing the bug check if this workaround works for them ?
Comment 12•21 years ago
|
||
(In reply to comment #11)
> In reply to Bug 228904 comment 10:
>
> This bug is reported against v1.7x ... but only v1.6 (working) and v1.7b (buggy)
> are mentionned:
> Could someone who is seeing the bug test and report about v1.7a ?
The checkin of the fix for the other bug was on 03/03/2004. And the other bug
duped to this says "Stange
thing is the first time I try a new build since 2004030308 it works the first
time I try opening preferences but it fails redrawing it the next time I try it."
So i think it's a checkin within 1-3 days before this date (also see the other
build its mentioned in this bugs, these people were using/testing nightlies).
Comment 13•21 years ago
|
||
(In reply to comment #0)
> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7b) Gecko/20040304
> Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7b) Gecko/20040304
>
> Preference Panel can be accessed only once per launch of Moz. Suite 1.7x. If a
> second attempt to access the panel is made w/i the same session, panel is not
> displayed and behaves as a "no-op" or nil condition, i.e. no action. Pref.
> panel, when displayed is milling entries in its left pane. Left Pane is blank.
> This condition does not occur in Moz. 1.6.
>
> Reproducible: Always
> Steps to Reproduce:
> 1. Launch Moz. 1.7x
> 2. Click on "Preferences" in "Mozilla" drop-down menu in toolbar.
> 3. Preference Panel will display with its left pane blank.
> 4. Click "OK" and panel closes.
> 5. Repeat step #2. Panel will not be displayed.
>
>
>
> Actual Results:
> 1. Flawed Preference Panel is displayed once.
> 2. Panel will not display a second time.
>
> Expected Results:
> Moz. Suite should properly display its Preference Panel as many times as
> required by the user in the same session, w/o relaunching.
>
> This condition may be unique to the Mac OSX version of Mos. Suite 1.7x
(In reply to comment #0)
> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7b) Gecko/20040304
> Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7b) Gecko/20040304
>
> Preference Panel can be accessed only once per launch of Moz. Suite 1.7x. If a
> second attempt to access the panel is made w/i the same session, panel is not
> displayed and behaves as a "no-op" or nil condition, i.e. no action. Pref.
> panel, when displayed is milling entries in its left pane. Left Pane is blank.
> This condition does not occur in Moz. 1.6.
>
> Reproducible: Always
> Steps to Reproduce:
> 1. Launch Moz. 1.7x
> 2. Click on "Preferences" in "Mozilla" drop-down menu in toolbar.
> 3. Preference Panel will display with its left pane blank.
> 4. Click "OK" and panel closes.
> 5. Repeat step #2. Panel will not be displayed.
>
>
>
> Actual Results:
> 1. Flawed Preference Panel is displayed once.
> 2. Panel will not display a second time.
>
> Expected Results:
> Moz. Suite should properly display its Preference Panel as many times as
> required by the user in the same session, w/o relaunching.
>
> This condition may be unique to the Mac OSX version of Mos. Suite 1.7x
(In reply to comment #12)
> (In reply to comment #11)
> > In reply to Bug 228904 comment 10:
> >
> > This bug is reported against v1.7x ... but only v1.6 (working) and v1.7b (buggy)
> > are mentionned:
> > Could someone who is seeing the bug test and report about v1.7a ?
>
> The checkin of the fix for the other bug was on 03/03/2004. And the other bug
> duped to this says "Stange
> thing is the first time I try a new build since 2004030308 it works the first
> time I try opening preferences but it fails redrawing it the next time I try it."
> So i think it's a checkin within 1-3 days before this date (also see the other
> build its mentioned in this bugs, these people were using/testing nightlies).
(In reply to comment #0)
> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7b) Gecko/20040304
> Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7b) Gecko/20040304
>
> Preference Panel can be accessed only once per launch of Moz. Suite 1.7x. If a
> second attempt to access the panel is made w/i the same session, panel is not
> displayed and behaves as a "no-op" or nil condition, i.e. no action. Pref.
> panel, when displayed is milling entries in its left pane. Left Pane is blank.
> This condition does not occur in Moz. 1.6.
>
> Reproducible: Always
> Steps to Reproduce:
> 1. Launch Moz. 1.7x
> 2. Click on "Preferences" in "Mozilla" drop-down menu in toolbar.
> 3. Preference Panel will display with its left pane blank.
> 4. Click "OK" and panel closes.
> 5. Repeat step #2. Panel will not be displayed.
>
>
>
> Actual Results:
> 1. Flawed Preference Panel is displayed once.
> 2. Panel will not display a second time.
>
> Expected Results:
> Moz. Suite should properly display its Preference Panel as many times as
> required by the user in the same session, w/o relaunching.
>
> This condition may be unique to the Mac OSX version of Mos. Suite 1.7x
Comment 14•21 years ago
|
||
(In reply to comment #13)
This previous comment seems to be "cut&paste" only: ignore it...
Comment 15•21 years ago
|
||
With Saturday build for PC linux samething. On first bring up Mozilla I can open
Preference Window as many times as I want with no problem. Close Mozilla and
reopen Mozilla in a short amount of time and it does not it will not render the
Preference Window correct.If I close the session out and wait a while it may or
may not on reopening of Mozilla display the screen correct it is a 50/50 gamble.
This is a change because before Saturday's Linux build it would be everytime
after the first time the Mozilla build would come up the Preference Window would
not disply correct.Hope that helps.
Comment 16•21 years ago
|
||
I just tested; deleting XUL.mfl does the trick for me too.
Comment 17•21 years ago
|
||
There is a better workaround too. Delete XUL.mfl and create new file (text
document, or any other), name it XUL.mfl and make it read only. That way,
Mozilla won't be able to write and break stuff. This does the trick so far for
me at least. I would like to QA this bug, it would be very nice if anyone could
put me.
Comment 18•21 years ago
|
||
(In reply to comment #16)
> I just tested; deleting XUL.mfl does the trick for me too.
jrgm:
Could you have a look at it ?
Updated•21 years ago
|
Blocks: profile-corrupt
Comment 19•21 years ago
|
||
this bug is not limited to the preferences window. Many other dialogs are coming
up with a bad width....for instance the progress dialog in mail compose after
sending a message.
Comment 20•21 years ago
|
||
*** Bug 236769 has been marked as a duplicate of this bug. ***
Comment 21•21 years ago
|
||
WFM Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b)
Gecko/20040303 with new profile. This build was Mozilla-trunk-2004030305. In
comment #1, I confirmed this bug on Mozilla-trunk-2003030405 with new profile.
It seemed that this regression occurred between 2004/03/03 and 2004/03/04.
Comment 22•21 years ago
|
||
This could very well be the same as bug 236619 for which i just checked in a
fix. The problem affects any style-attributes loaded through fastload. So if the
width is specified using something like style="width: 117px" then that could
certainly break.
The problem is not in the actual loading of the fastload file, but rather in
serializing the prototype-document.
Comment 24•21 years ago
|
||
Still the problem with Moz 1.7b 2004030708 WinNT4 OrbitRetro Theme.
(In reply to comment #0)
> Reproducible: Always
> Steps to Reproduce:
> 1. Launch Moz. 1.7x
> 2. Click on "Preferences" in "Mozilla" drop-down menu in toolbar.
> 3. Preference Panel will display with its left pane blank.
> 4. Click "OK" and panel closes.
> 5. Repeat step #2. Panel will not be displayed.
For me step 5 works like step 3. It is always displayed like in attachment
142926 [details]. Sometimes I see other dialogs with strange (to small) size like the
download progress dialog. But there it works the second time and later during a
session.
Shouldn't this be a blocker or at least relnote?
Reporter | ||
Comment 25•21 years ago
|
||
(In reply to comment #24)
> Still the problem with Moz 1.7b 2004030708 WinNT4 OrbitRetro Theme.
>
> (In reply to comment #0)
> > Reproducible: Always
> > Steps to Reproduce:
> > 1. Launch Moz. 1.7x
> > 2. Click on "Preferences" in "Mozilla" drop-down menu in toolbar.
> > 3. Preference Panel will display with its left pane blank.
> > 4. Click "OK" and panel closes.
> > 5. Repeat step #2. Panel will not be displayed.
>
> For me step 5 works like step 3. It is always displayed like in attachment
> 142926. Sometimes I see other dialogs with strange (to small) size like the
> download progress dialog. But there it works the second time and later during a
> session.
>
> Shouldn't this be a blocker or at least relnote?
Do you want it posted as blocker of 1.7b, or what?
Comment 26•21 years ago
|
||
Updating:
+(F) blocking1.7b=?
I'm not using nighlies, so I have not (yet) experienced this bug,
but, based on comments, it seems to be a major UI regression.
Flags: blocking1.7b?
Reporter | ||
Comment 27•21 years ago
|
||
(In reply to comment #26)
> Updating:
> +(F) blocking1.7b=?
>
> I'm not using nighlies, so I have not (yet) experienced this bug,
> but, based on comments, it seems to be a major UI regression.
Sounds good to me!
Comment 28•21 years ago
|
||
*** Bug 236711 has been marked as a duplicate of this bug. ***
Comment 29•21 years ago
|
||
I tested today's MacOSX build (2004030905), and this problem seemed to be gone.
Mozilla displays properly its Preferences panel.
Comment 30•21 years ago
|
||
I don't see it either. Markng this bug as fixed since it looks like Jonas's
patch did indeed fix it yesterday.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 31•21 years ago
|
||
Same thing here on Linux PC with build id 2004030908 no problem. Working normal.
Reporter | ||
Comment 32•21 years ago
|
||
It appears that the problem still exists, at least with the 20040309 Mac
version of Moz. Suite 1.7.
Updated•21 years ago
|
Flags: blocking1.7b?
Reporter | ||
Updated•21 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reporter | ||
Updated•21 years ago
|
Whiteboard: See Attachment # 143418 & Comment #32.
Comment 33•21 years ago
|
||
can others confirm on the Mac? jonas can you look at this?...
Flags: blocking1.7b?
Comment 34•21 years ago
|
||
Moz 1.7b 2004030909 WinNT4 OrbitRetro theme
(In reply to comment #24)
> Sometimes I see other dialogs with strange (to small) size like the
> download progress dialog. But there it works the second time and later during
a
> session.
Pref Panel works now but on the first download attempt I get a wrongsized DL
window (see attachment). For subsequent downloads the dialog is ok.
Comment 35•21 years ago
|
||
(In reply to comment #32)
> Created an attachment (id=143418)
> Moz. 1.7x Pref Panel fails to display properly and can only be accessed once
> per Suite launch.
>
> It appears that the problem still exists, at least with the 20040309 Mac
> version of Moz. Suite 1.7.
Did you use the default theme(classic)? In comment #2, I used the default
theme(classic). It seemed that you used Okhotska theme. Try the default theme.
The last update of Okhotska for Mozilla suite is Jan. 18th, 2004. Perhaps, the
current versions of third-party themes don't support for Mozilla-trunk yet. For
example, Pinball theme has a few problems on Mozilla-trunk(20040309). When I
click "Bookmarks" on personal toolbar, Mozilla displays weird bookmarks.
Reporter | ||
Comment 36•21 years ago
|
||
Reporter | ||
Comment 37•21 years ago
|
||
(In reply to comment #35)
> Created an attachment (id=143500)
> Same problem with "Classic" Theme: Pref Panel failure
>
Reporter | ||
Comment 38•21 years ago
|
||
And we may have a problem.... at least for Mac users....? HOWEVER, with 1.6 I
can open/close Prefs and then reopen and everything is OK! (I like to be
complete)
Comment 39•21 years ago
|
||
Gordon, I realize that this was your bug originally but since it was morphed
into the now fixed bug with dialogs (including prefs) being sized incorrectly,
I've filed a new bug 237279 for your issue and I'm resolving this one.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → WONTFIX
Updated•21 years ago
|
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → WORKSFORME
Updated•21 years ago
|
Flags: blocking1.7b?
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•