Customize window look funny (titlebar, minimize/maximize/close buttons present) in latest builds when using Classic XP style




14 years ago
7 years ago


(Reporter: berkut.bugzilla, Assigned: bugs)


({fixed-aviary1.0, regression})

Windows XP
fixed-aviary1.0, regression
Bug Flags:
blocking-aviary1.0 +

Firefox Tracking Flags

(Not tracked)



(2 attachments, 1 obsolete attachment)



14 years ago
I am not sure when it regressed, or if this is limited to my configuration.
However, this happens when Windows XP is set to classic style. This is best
described with a screenshot...

Comment 1

14 years ago
Created attachment 160626 [details]

Comment 2

14 years ago
just tried it with a clean new profile: same problem

Comment 3

14 years ago
Can't reproduce in Gecko/20040928 Firefox/0.10.

Comment 4

14 years ago
This is probably a regression from the checkin for bug 245088.

This was the checkin:

Ross, since this checkin was after your build was made, you cannout see this. 
Please update and try again. I'm adding the regression keyword. Please ask for
blocking-status if you can confirm this, since this is a serious visual blocker.

I can't confirm this, since I'm on W2K here.
Severity: minor → normal
Keywords: regression

Comment 5

14 years ago
Good call Simon. Reproduced in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.3) Gecko/20040929 Firefox/0.10 on WinXP.

Functionality is not affected (the minimise, maximise, close buttons don't do
anything), but it looks broken. Requesting blocking.
Flags: blocking-aviary1.0?


14 years ago
Ever confirmed: true
hey Asa, this is this issue you showed me --did you already file a bug on it?


14 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0+


14 years ago
Summary: Customize window look funny in latest builds when using Classic XP style → Customize window look funny (titlebar, minimize/maximize/close buttons present) in latest builds when using Classic XP style
*** Bug 262650 has been marked as a duplicate of this bug. ***
Created attachment 160954 [details] [diff] [review]

don't hide chrome anymore
Last Resolved: 14 years ago
Resolution: --- → FIXED


14 years ago
Keywords: fixed-aviary1.0

Comment 9

14 years ago
The window shouldn't have maximize or minimize buttons.  I'm going to re-open
this to get Ben's attention.
Resolution: FIXED → ---

Comment 10

14 years ago
Created attachment 161705 [details] [diff] [review]
remove slop

This patch makes sure that the titlebar does not appear using both Classic and
WinXP styles in WinXP. This patch has the added advantage of also making sure
that top of the customize window touches the navigation toolbox (curent builds
have a few pixel gap). I don't have access to a machine running Linux, so
someone will have to make sure this doesn't break anything (I don't think it


14 years ago
Attachment #161705 - Flags: review?(bugs)

Comment 11

14 years ago
Other sources have confirmed that this is not fully fixed. Removing the
fixed-aviary1.0 keyword.

Ben, if you intended for the window to have a titlebar, than feel free to mark
this fixed again, with my apologies for the bugspam.
Keywords: fixed-aviary1.0

Comment 12

14 years ago
Jim, look at comment 8.  Ben specifically removed the "hidechrome" attribute in
that patch.  So in response to your comment 11, his intention is definitely to
show the titlebar.

The only reason I re-opened this was to get Ben's attention to what I stated in
comment 9.  You shouldn't be able to minimize nor maximize the customize dialog.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-

Comment 13

14 years ago
Yeah Dean, I saw that. I interpreted this bug to mean that the reporter thought
that a titlebar should not be there. The patch Ben landed fixes the fact that
the titlebar (and window controls on it) were previously borked, but I am still
confused why we even want a titlebar. Furthermore, with the max/min buttons
hidden, you can still resize/move the customize window... do we want this as
well? The patch I attached removes the titlebar again and doesn't show a broken
titlebar under classic view (at least from my own testing). I also tied it under
several extreme browser resizes/locations (very small window, near the windows
taskbar, etc.) and the customize window behaved properly.

Comment 14

14 years ago
I really hope Ben is going to approve your patch before 1.0 Jim.
I do not think Ben deliberately changed the Customize Toolbar sheet (window?)
look, perhaps the lack of time is forcing this kind of measures.

Comment 15

14 years ago
Now that I look at it, IE creates a window when customizing, so that may be what
we are trying to emulate. Personally, I like the look of the older method and I
think it conveys drag-and-drop better than using an external window (as opposed
to the IE customize window where all customization occurs within the external
window, independent of the browser window.)  Either way, the customize window is
fine for now and if one of the devs finds some free time they can consider the
attached patch.

Comment 16

14 years ago
Comment on attachment 161705 [details] [diff] [review]
remove slop

Sorry to waste everyone's time. This is intended.
Attachment #161705 - Attachment is obsolete: true
Attachment #161705 - Flags: review?(bugs)

Comment 17

14 years ago
Re-resolving as fixed and splitting off "incompleteness" into:

Bug 264488 Customize Toolbars window should not have maximize or minimize buttons
Bug 264489 Customize Toolbars window should remember its size
Last Resolved: 14 years ago14 years ago
Flags: blocking-aviary1.0- → blocking-aviary1.0+
Keywords: fixed-aviary1.0
Resolution: --- → FIXED


12 years ago
QA Contact: bugzilla → toolbars
You need to log in before you can comment on or make changes to this bug.