172903 - OS/2 only - customizing toolbar doesn't work

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[Mike Kaply [:mkaply]]

This is very strange. I'm not assigning it to me because I hope to get some advice.

On OS/2, the customize toolbar window is coming up as 0x0.

If I resize it with a utility, it works fine.

Is there anything special about how this window is put up?

The only thing that comes to mind is that the size is set on window creation and
never resized, which is inconsistent with other Mozilla windows...

Comment 1

[Mike Kaply [:mkaply]]

Definitely has nothing to do with window creation.

I've no idea why this window behaves differently than other Mozilla windows.

I'm going to look at that Windows on Windows and see what the difference is.

Comment 2

[Mike Kaply [:mkaply]]

OK, the XUL for customizing toolbar is really screwed up. Is that a window or a
dialog?

If I change window to dialog, I get something to come up on Os/2 at least.

The customizing UI seems like a pretty bastardized thing. Is that the final UI?

Having a window with no chrome at all seems pretty bad.

Comment 3

[Mike Kaply [:mkaply]]

Getting closer.

The slideOpen seems to not be happening.

If I explicitly set window.outerHeight, I get a window.

Comment 4

[Mike Kaply [:mkaply]]

OK, I have no explanation, but I know what is happening.

in slideOpen, the window.outerHeight += kAnimateIncrement is not actually
affecting window.outerHeight - it is staying 0.

I have verified that kAnimateIncrement is 50, and the line is executed, but
after outerheight += kAnimateIncrement, outerheight is still 0.

Figure that one out.

Comment 5

[Mike Kaply [:mkaply]]

OK, I have the answer.

On Os/2, when you set a window size to 600 x 0, it gets set to 0x0. Os/2 can't
maintain a width if there is no height (seems logical to me)

So the issue is that the first time we come through the code in customizing
toolbar, we set the size to 600x0.

This seems wrong to me anyway.

I'll put together a patch to fix this in customizetoolbar.js.

I see no way to fix this on the Os/2 side.

Comment 6

[Mike Kaply [:mkaply]]

Attachment: Rewrite of slideout code

I initialize the windowheight to 50 and then set the timer to cause slideOut to
get called again.

Also, inside slideout, I use the height of the window to determine when to
stop, I don't count steps.

Same changes for slideClosed

Comment 7

[Mike Kaply [:mkaply]]

Please will SOMEONE look at this bug with path?

I'd like to have an Os/2 Phoenix without private fixes pretty please

Comment 8

[Joe Hewitt (gone)]

Michael, my original slideout code checked the height instead of using steps,
but that broke Linux which didn't always report the actual height of the window.

Comment 9

[Blake Ross]

This patch will break Linux; we used to do what it does and changed to steps
purposely.

Joe Hewitt is really the one to talk to about this code, it's his.  You could
try e-mailing him, but it's best to catch him on irc or AIM.

Comment 10

[Joe Hewitt (gone)]

Wait up, my previous comment is inaccurate.  I changed to using steps because on
some systems, win98 I think, there were cases where during the slideClosed
animation, the height of the window would never shrink beyond a certain
threshold, even if I told it to.

Comment 11

[Mike Kaply [:mkaply]]

Interesting. Well I think the assumption here that you can set a window to 600x0
and then query the width and get back 600 is incorrect.

Width is not necessarily defined if height is not > 0.

All I need for OS/2 is to simple not set the height to 0 initially. Even just
setting it to 1 fixes this problem for us. 

Of course then, everything is 1, 51, 101, etc.

Comment 12

[Mike Kaply [:mkaply]]

What about just starting at 50 instead of 0? Visually, there shouldn't be any
difference. The window starts not being there.

Comment 13

[Mike Kaply [:mkaply]]

Attachment: Good fix

Start at 50 and subtract one from the increment.

Makes NO difference visually.

URGENTly needed for OS/2

Comment 14

[Mike Kaply [:mkaply]]

This prevents the OS/2 build from functioning.

Comment 15

[Brian Ryner (not reading)]

checked in.

Comment 16

[Simon Paquet [:sipaq]]

Taking QA Contact

Comment 17

[Simon Paquet [:sipaq]]

verified fixed 2003-11-09