Closed (fixed)
Project:
Boxes
Version:
7.x-1.x-dev
Component:
User interface
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
1 Dec 2011 at 16:55 UTC
Updated:
8 Feb 2012 at 18:40 UTC
Jump to comment: Most recent file
The text input fields of the boxes configuration form needs some CSS to set the width to 100% so that it doesn't extend outside of the region. I added a screen caption of a very vanilla website using Omega theme and box.
Comments
Comment #1
jec006 commentedI believe the best way to fix this is to show the edit form inside a popup box. Simply constraining the width to stay inside of the region will result in cutoff form areas (for example, a select list with a long option, or a wysiwyg enabled text area).
A popup would allow for the box edit form to be displayed without having to contend with the other elements of the page or having to worry about the width or height of the region its placed in.
I'm attaching a patch to do this, it utilizes the jquery ui dialog library, which is already included in core for d7.
This patch needs some testing, works great with the simple box on rubik, but unsure with more complex boxes in other themes.
Comment #2
jec006 commentedAh, missed one thing - a user could click the x without clicking a button - in which case we want to just click the cancel button and remove the form ect.
Here is an updated patch.
Comment #3
tirdadc commentedTested on Chrome, FF and IE and it works amazingly well. So much better.
Comment #4
twohlix commentedTested on a demo site of a production install in Chrome. Works great! Thanks so much.
Comment #5
tirdadc commentedCommitted and changing the issue's title.
Comment #6
tirdadc commentedJust thought I'd mention that this works once the box has already been placed and instantiated for now, ie not during the initial drag and drop phase. Given that some boxes have the multi-page form capability, enabling this from the onset may be a bit more complicated and would require a bit more investigation.
Comment #7
jec006 commentedComment #8
jec006 commentedHere's another (additive patch) which adds support for multistep forms (i.e. Views Boxes) and also better handles form errors (failing to fill out the title ect.
It also needs testing with various box types ect.
Comment #9
jec006 commentedHere is another go at the patch in 8 which has some bug fixes and moves the ajax commands outside the behavior so we don't have to create them every time the behavior gets called.
There are still outstanding bugs - particularly with views boxes.
Comment #10
tirdadc commented#9 (along with the patch that was initially committed) had some issue where additional JS files weren't getting attached properly when editing boxes, which caused JSON to be returned in certain cases instead of the expected behavior.
This patch fixes that and can be tested with a curated views box. I also made the pop-up's width slightly larger.
Comment #11
twohlix commented#10 works with view boxes. Autocomplete works.
Just noticed a different issue while testing: when hitting enter on an autocomplete item it submits the form but doesnt actually save (separate issue outside this issue's scope).
Comment #12
tirdadc commentedPushed #10, it's working fine with regular / views / entity boxes.
The 'Enter' issue is tied to Views Boxes, since hitting that key while the focus is on a top-level box field (ie title, description, etc...) works fine (it submits the form with the right values).