Opened 9 years ago

Closed 9 years ago

#10398 closed defect (fixed)

fullscreen Editor in ContentPane of a BorderContainer

Reported by: roaming Owned by: Jared Jurkiewicz
Priority: high Milestone: 1.4
Component: Editor Version: 1.4.0b
Keywords: Cc: Adam Peller, Jared Jurkiewicz, bill
Blocked By: Blocking:

Description

Editor in a ContentPane? of a BorderContainer? does not "break out" of the ContentPane? to expand to fullscreen.

Attachments (4)

test_BorderContainer_complex2.html (61.9 KB) - added by roaming 9 years ago.
fullscreen.patch (2.3 KB) - added by Jared Jurkiewicz 9 years ago.
Potential work around to get FS working from within LayoutContainers? since we can't reparent the editor (iframe reloads and breaks stuff)
test_FullScreen.html (3.1 KB) - added by bill 9 years ago.
testcase that fails on return to normal size
firebug.png (49.2 KB) - added by bill 9 years ago.
screenshot where editor's scrollbar is offscreen; using firebug to show actual size of editor (overflowing it containing ContentPane?)

Download all attachments as: .zip

Change History (12)

Changed 9 years ago by roaming

comment:1 Changed 9 years ago by Adam Peller

Cc: Adam Peller Jared Jurkiewicz added
Component: GeneralEditor
Owner: anonymous deleted

comment:2 Changed 9 years ago by bill

Owner: set to Jared Jurkiewicz

comment:3 Changed 9 years ago by Jared Jurkiewicz

Cc: bill added

The problem is that the BorderContainer? sets position: absolute !important in several styles. This jam sup the resizing of the editor. The two possible solutions are:

1.) Move editor temporarily out to body when FS. This has a major problem, editor refires onload on the iframe when you do that. Ugh. That messes up a lot of stuff

2.) Try to disable/bypass those styles somehow. I have a prototype that walks up the hierarchy of parents of editor and teporarily removes all their classes ... but that has other possible issues ... such as removing your THEME class if it isn't defined on <body>.

3) Just remove the BorderContainer? classes temporarily when in FS mode. This has an issue if the classes ever change names, or other classes end up doing the same sort of thing (set pos: absolute and such).

Need input on alternatives. Bill? Is there a way to detect and over-ride !important styles via dojo.style? I can walk up the parents and find the divs with position settings, but I don't know how to over-ride (or even detect), that !important.

comment:4 Changed 9 years ago by bill

Note there are also probably problems when the user resizes the browser while the editor is in full screen mode. BorderContainer/TabContainer/etc. will try to resize the Editor, which will either cause a JS exception (if the editor's domNode has been moved to <body>) or will do something unwanted (if the editor has been maximized).

Things need to work correctly when the browser is resized, and then also afterwards, when the editor is returned from full size mode to embedded mode.

Changed 9 years ago by Jared Jurkiewicz

Attachment: fullscreen.patch added

Potential work around to get FS working from within LayoutContainers? since we can't reparent the editor (iframe reloads and breaks stuff)

comment:5 Changed 9 years ago by Jared Jurkiewicz

Resolution: fixed
Status: newclosed

(In [20921]) Tweaking FullScreen? to work better in layout containers. fixes #10398

comment:6 Changed 9 years ago by Jared Jurkiewicz

Milestone: tbd1.4

Targeting 1.4, as Bill okayed this going into dijit for RC2

comment:7 Changed 9 years ago by bill

Resolution: fixed
Status: closedreopened

Thanks for the fix. I tried it out and I see the problem I was worried about, when the editor has the wrong size upon leaving full screen mode. I'm attaching a test case (a modified version of test_FullScreen.html).

Steps to reproduce the problem:

  1. Load URL. Editor should show up w/a scrollbar (if not, then make your browser window smaller until scrollbar appears).
  2. Change Editor to full screen mode.
  3. Make browser window smaller.
  4. Go back to normal mode.

At this point the scrollbar is not visible because the editor overflows the center ContentPane.

See attached screenshots also.

I saw this on FF3.5/mac although it probably happens on other browsers too. IE is a little special since it sets width and height on the center ContentPane, rather than right and bottom. I don't think that will affect things though.

PS: I don't understand roaming's test_BorderContainer_complex2.htm example, it looks like the output in firebug after dijit has instantiated all the widgets (with widgetid=... specified on each node).

Changed 9 years ago by bill

Attachment: test_FullScreen.html added

testcase that fails on return to normal size

Changed 9 years ago by bill

Attachment: firebug.png added

screenshot where editor's scrollbar is offscreen; using firebug to show actual size of editor (overflowing it containing ContentPane?)

comment:8 Changed 9 years ago by Jared Jurkiewicz

Resolution: fixed
Status: reopenedclosed

(In [20934]) Have fullscreen do a check when reducing back that if it's in a layout container, call resize on it to properly scale. fixes #10398

Note: See TracTickets for help on using tickets.