Opened 9 years ago

Closed 9 years ago

#11905 closed defect (fixed)

Dialog: does not position centered depending on content and window size

Reported by: Nick Fenwick Owned by:
Priority: high Milestone: 1.6
Component: Dijit Version: 1.5
Keywords: Cc:
Blocked By: Blocking:

Description

dojo 1.5.0 on firefox 3.6.12, also tested on chrome 7.0.517.41.

Not sure if this is a bug. A dijit.Dialog appears off-center (in my case, butting against the right edge of the window) depending on the content put in it and the size of the window when show() is called.

This jsfiddle demonstrates the problem. If you resize the lower right pane to match the width of the smaller dotted box and hit Run, the Dialog should appear off-center. If you resize the pane to match the larger dotted box and hit Run, it centers OK.

http://jsfiddle.net/neekfenwick/9fnpA/2/

Note that I'm not setting the width of the dialog in any way. In my real app, if I define the width of the content (e.g. 30em), this problem goes away, but only because I'm constraining the sizes involved to safe values.

A little debugging of the Dialog._position code:

For example in one of my tests I had a window width of 928px, and if the dialog is allowed to appear I can see its width is 693px, the initial _position code (which is called twice during Dialog.show()) is returned a valid bb of {t: 0, l: 0, w: 462, h: 173}, so the position of the Dialog is going to be set to 233,77 .. this is not correct, because the 'w' of the BoundingBox? was only 462 and should have been 693.

I'm not sure where to continue investigating this, and have a feeling you guys will just say "invalid" because it can be worked around.

Attachments (1)

11905.html (1.2 KB) - added by Nick Fenwick 9 years ago.
Simple test case, uses google cdn.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 9 years ago by ben hockey

i hope it's not invalid... i've seen the same problem but wasn't able to reproduce it as simply as you have. i also have ended up with the same workaround - i have to explicitly set the width of my content in some cases.

comment:2 Changed 9 years ago by bill

Not sure I follow, what do you mean by the "BoundingBox"?

Previously we fixed a problem with tooltip where the tooltip's "natural" width (a.k.a. the "unconstrained width") was reported at most as half of the viewport width. Turned out the problem was that we were measure the tooltip's width while it was set to left:50% rather than left:0. Maybe that's the problem here.

comment:3 in reply to:  2 Changed 9 years ago by Nick Fenwick

Replying to bill:

Not sure I follow, what do you mean by the "BoundingBox"?

Sorry, I made two errors in my original description.

The 'bb' I referred to is actually BorderBox?, it seems. The position() code includes:

bb = p ? null : dojo._getBorderBox(node)

and the 'bb' that is returned is incorrect with respect to the actual content that will appear on screen.

I also did not mean to say that the bb was 'valid' as in 'correct'. By 'valid', I meant that the function returns sanely with a suitably populated object. Still, its values are incorrect, which leads to a positioning error.

I do not have my head around the dojo BorderBox? calculations.. as soon as I have to drill into functions like _getPadExtents and _getContentBox my head starts to spin.

Previously we fixed a problem with tooltip where the tooltip's "natural" width (a.k.a. the "unconstrained width") was reported at most as half of the viewport width. Turned out the problem was that we were measure the tooltip's width while it was set to left:50% rather than left:0. Maybe that's the problem here.

No idea.. quite possibly. I'm not familiar with the term 'unconstrained width'. If you mean that the width of a text string that does not wrap is 'unconstrained' and the width of the same string when wrapped would be 'constrained' by the wrapping, then that's not the case.. the bug occurs when the single line of text in the Dialog content is rendered all on one line and not wrapped. I really think someone better versed with layout should debug this - my jsfiddle was a very basic scenario demonstrating the problem.

comment:4 Changed 9 years ago by bill

Summary: dijit.Dialog does not position centered depending on content and window sizeDialog: does not position centered depending on content and window size

Yes, "unconstrained width" isn't an official term, but I meant the width of the unwrapped text string, or more specifically the width the Dialog would be if it wasn't constrained by the width of the viewport.

Can you attach a small test case (a single HTML file) so I can use it to debug? The link you have is 10 pages long (and is also very slow to bring up).

Changed 9 years ago by Nick Fenwick

Attachment: 11905.html added

Simple test case, uses google cdn.

comment:5 Changed 9 years ago by Nick Fenwick

bill - have attached a simple .html file. It demonstrates the problem to me, using firefox 3.6.12 on linux.

If the jsfiddle page appeared 10 pages long to you, it must be broken, but I'm not going to get into that here. This test page is a direct copy of the jsfiddle pieces into a template html file using google CDN dojo 1.5.0.

comment:6 Changed 9 years ago by bill

Milestone: tbd1.6
Resolution: fixed
Status: newclosed

Thanks, that's a much better test case. I show this being inadvertently fixed by [22835]. Not sure why that fixed it but I guess I'll leave things as they are unless the problem recurs.

Note: See TracTickets for help on using tickets.