Last Comment Bug 102440 - Mozilla obeys invalid maxwidth attribute on text form controls
: Mozilla obeys invalid maxwidth attribute on text form controls
Status: VERIFIED FIXED
: dev-doc-complete, testcase
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: Trunk
: All All
: P4 normal (vote)
: mozilla6
Assigned To: David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
:
Mentors:
http://www.amoebamusic.com/index2.html
: 131597 207373 645137 (view as bug list)
Depends on: 216838 644514
Blocks: 659982
  Show dependency treegraph
 
Reported: 2001-09-30 11:39 PDT by Stephen Moehle
Modified: 2011-07-28 05:46 PDT (History)
10 users (show)
dbaron: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Simplified test case (594 bytes, text/html)
2001-09-30 11:40 PDT, Stephen Moehle
no flags Details
Another testcase showing the problems this causes (365 bytes, text/html)
2011-03-25 12:54 PDT, Boris Zbarsky [:bz]
no flags Details
patch (16.58 KB, patch)
2011-04-19 17:50 PDT, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
bzbarsky: review+
Details | Diff | Splinter Review

Description Stephen Moehle 2001-09-30 11:39:29 PDT
The above url has a form with an text input that has a maxwidth attribute:

<INPUT TYPE="TEXT" NAME="email" SIZE="30" maxwidth="40">

As far as I can tell, there is no version of HTML that has a maxwidth attribute
for text input controls.  I think the author of the page probably meant
maxlength, but I really am not sure.

Mozilla, however, obeys this maxwidth attribute rendering the text control 40
pixels wide.  In fact it takes it over the size attribute which has a reasonable
value.  As a result, the form is unusable in Mozilla as the text input control
is far too narrow to actually type in.

Both NN4 and Opera ignore the maxwidth attribute and render the text control 30
characters wide which is what I think Mozilla should do as well.

Tested with Mozilla trunk build 2001092906 on Linux.
Comment 1 Stephen Moehle 2001-09-30 11:40:32 PDT
Created attachment 51462 [details]
Simplified test case
Comment 2 Boris Zbarsky [:bz] 2001-09-30 15:44:44 PDT
confirming.  <div> elements do not seem to do maxwidth..

now, we have maxwidth in XUL, but I don't see how this would affect HTML
elements....
Comment 3 rods (gone) 2001-11-06 09:12:38 PST
The problem is the GfxText uses the nsBox for part of it's sizing and the 
method:
nsIBox::AddCSSMaxSize(nsBoxLayoutState& aState, nsIBox* aBox, nsSize& aSize)

Checks for a XULATom:maxwidth and name space none and it should really only be 
looking at the XUL namespace.

Or somehow the nsBox needs to NOT do this when sizing an HTML control.

Over to evaughan
Comment 4 Kevin McCluskey (gone) 2001-12-19 15:40:19 PST
Reassigning to Alex.
Comment 5 Tuukka Tolvanen (sp3000) 2002-03-17 12:12:43 PST
*** Bug 131597 has been marked as a duplicate of this bug. ***
Comment 6 Robert Towster 2002-04-29 19:27:34 PDT
I also see this on Win2k using RC1 (build id: 2002041711). 

This html:
<input type="text" name="foo" maxwidth="3" size="5">
displays on mozilla as a VERY thin line.
In IE 5.5 and netscape 4.7 it displays as a text box.

Comment 7 Bill Mason 2003-05-28 11:39:33 PDT
*** Bug 207373 has been marked as a duplicate of this bug. ***
Comment 8 Bill Mason 2003-05-28 14:52:11 PDT
OS->all based on last 2 comments
Comment 9 Vedran Miletic 2003-10-05 08:22:18 PDT
retargeting
Comment 10 Boris Zbarsky [:bz] 2003-10-05 11:27:18 PDT
We should just move the maxwidth XUL stuff into the XUL attribute-mapping code
(which we should create).
Comment 11 Boris Zbarsky [:bz] 2011-03-25 12:54:11 PDT
*** Bug 645137 has been marked as a duplicate of this bug. ***
Comment 12 Boris Zbarsky [:bz] 2011-03-25 12:54:44 PDT
Created attachment 521915 [details]
Another testcase showing the problems this causes
Comment 13 Glen 2011-03-25 13:20:21 PDT
(In reply to comment #11)
> *** Bug 645137 has been marked as a duplicate of this bug. ***

Thanks, Boris.  I just needed to use a different name, other than maxWidth, for my custom attribute name.
Comment 14 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2011-04-19 17:50:27 PDT
Created attachment 527168 [details] [diff] [review]
patch

This started off as bug 644514 patch 2, but it really doesn't have anything to do with that bug, and a lot to do with this one, so let's put it here.
Comment 15 Boris Zbarsky [:bz] 2011-04-20 19:59:40 PDT
Comment on attachment 527168 [details] [diff] [review]
patch

r=me, but add some tests, please?
Comment 16 neil@parkwaycc.co.uk 2011-04-21 16:55:06 PDT
Comment on attachment 527168 [details] [diff] [review]
patch

>           <html:input anonid="input"
>                       class="autocomplete-textbox urlbar-input textbox-input uri-element-right-align"
>-                      flex="1" allowevents="true"
>+                      style="-moz-box-flex: 1" allowevents="true"
Instead of inline style please put this in toolkit/content/textbox.css
Comment 17 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2011-04-22 16:01:13 PDT
ok... I also had to put it in menulist.css, since menulist.xml doesn't use the textbox-input class.
Comment 18 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2011-04-22 19:17:35 PDT
https://hg.mozilla.org/mozilla-central/rev/5b0b236704da
Comment 19 neil@parkwaycc.co.uk 2011-04-23 03:00:34 PDT
(In reply to comment #17)
> ok... I also had to put it in menulist.css, since menulist.xml doesn't use the
> textbox-input class.

That might be a bug, or it might be a limitation of XBL1. I'll look into it.
Comment 20 Eric Shepherd [:sheppy] 2011-04-24 18:40:31 PDT
Updated documentation by adding a note to Firefox 6 for developers; this was never documented as supported, so it's more of a relnote type issue.
Comment 21 Simona B [:simonab] 2011-07-28 05:46:12 PDT
Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20100101 Firefox/6.0

Verified issue on Windows XP, Windows 7, Mac OS X 10.6 and Ubuntu, using the test case from Comment 12. 

Setting resolution to VERIFIED FIXED.

Note You need to log in before you can comment on or make changes to this bug.