Opened 12 years ago

Closed 12 years ago

#4093 closed defect (fixed)

InlineEditBox: edit empty InlineEditBox, edit widget is too small

Reported by: haysmark Owned by: haysmark
Priority: high Milestone: 0.9
Component: Dijit Version: 0.9
Keywords: dijit inlineeditbox Cc:
Blocked By: Blocking:

Description

To reproduce:

  1. Open test_inlineeditbox
  2. Delete the text from a widget (any widget)
  3. Save
  4. Edit the same widget again

By design, the InlineEditBox? resizes the edit widget to the size of the text. But if there isn't any text, like in the case the user deletes the text, the edit widget becomes too small to edit. This is all by design, but is clearly wrong and thus this design needs to be addressed for 0.9.

Change History (7)

comment:1 Changed 12 years ago by bill

Oh you are talking about width not height. I think that for

<p dojotype=InlineEditBox>
  <textarea dojotype=TextArea>hello</textarea>
</p>

From an outsider's perspective, the <p> is display: block so it takes up the width of the viewport (or containing div), so the edit area should be the same.

For a

<span dojotype=InlineEditBox>
  <input dojotype=TextBox value="hello">
</span>

It's more difficult because sometimes we want the box to be inline (like for editing a number we'd want the width to just be 3em or something), so have to think about that one some more. But I guess for 0.9 just doing width:100% in all cases might get us close enough.

comment:2 Changed 12 years ago by haysmark

Owner: set to haysmark

I will set width to 100% then for 0.9.

comment:3 Changed 12 years ago by haysmark

Status: newassigned

comment:4 Changed 12 years ago by bill

Talked to Mark about this a while and also looked over the InlineEditBox? code.

The first problem here... I've filed it as bug #4097.

The second problem is that when the original srcNodeRef is display:block (examples: see anything in http://download.dojotoolkit.org/release-0.4.3/dojo-0.4.3-widget/tests/widget/test_InlineEditBox.html), it is being turned into a display:inline.

getComputedStyle() of an <h1>foo</h1> will return width == the browser window, but getComputedStyle() of a <span>foo</span> will return something like 20px. Thus the Editor is too small (this bug). It should be the width of the browser window.

The third problem deals with when the original element is inline (like a Combobox). In that case we want to specify some sort of width (more than the text width , but less than the browser width).

comment:5 Changed 12 years ago by bill

(In [10092]) InlineEditBox? inherits the block/inline behavior from its parent, which effectively sets a minimum size on the edit widget of one line if the source node was block. Refs #4093. Patch from Mark Hays.

comment:6 Changed 12 years ago by bill

(In [10093]) oops, didn't mean to check this in yet. reverting previous changes (until they are finished). refs #4093.

comment:7 Changed 12 years ago by Douglas Hays

Resolution: fixed
Status: assignedclosed

(In [10105]) Fixes #4093. Proxy commit for haysmark. Enabled the user to specify the width of their InlineEditBox? edit widgets in markup. Removed resize code from InlineEditBox? (conflicted with user's styling). Added widths to the edit widgets in test_InlineEditBox to demonstrate setting the width. Changed the spinner test source node to a span to be inline.

Note: See TracTickets for help on using tickets.