[FIX]Changing the type attribute of form controls needs to notify about various state changes

RESOLVED FIXED in mozilla1.9alpha1

Status

()

Core
CSS Parsing and Computation
P2
normal
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: bz, Assigned: bz)

Tracking

Trunk
mozilla1.9alpha1
x86
Linux
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 1 obsolete attachment)

Priority: -- → P2
Target Milestone: --- → mozilla1.9alpha
Created attachment 233949 [details] [diff] [review]
Like so
Attachment #233949 - Flags: superreview?(dbaron)
Attachment #233949 - Flags: review?(dbaron)
Note that I added more testcases for this sort of thing at http://web.mit.edu/bzbarsky/www/testcases/css-selectors/ a while back; the testcases that apply to this bug are in CVS with the appropriate filenames.

Comment 3

12 years ago
when this lands, please add the tests to mochitest.

It should look pretty much like this file:
/cvsroot/mozilla/testing/mochitest/tests/test_bug302186.html
Flags: in-testsuite?
Comment on attachment 233949 [details] [diff] [review]
Like so

> nsHTMLInputElement::IntrinsicState() const
> {
>+  // If you add states here, and they're type-depedent, you need to add them to

depe*n*dent

>Index: content/html/content/src/nsGenericHTMLElement.cpp
>+      if (doc) {

 && aNotify ?

>Index: content/html/content/src/nsHTMLFormElement.cpp

r+sr=dbaron
Attachment #233949 - Flags: superreview?(dbaron)
Attachment #233949 - Flags: superreview+
Attachment #233949 - Flags: review?(dbaron)
Attachment #233949 - Flags: review+
Created attachment 254503 [details] [diff] [review]
Updated to comments and tip, now with tests.
Attachment #233949 - Attachment is obsolete: true
Checked in, with tests and trumpets.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Check again! reftest.list is incorrectly referencing bugs/348801 instead of 348809. This is causing reftest to stall out.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Duplicate of this bug: 369856
Created attachment 254535 [details] [diff] [review]
reftest.list patch 348801->348809
Attachment #254535 - Flags: review?(dbaron)
Comment on attachment 254535 [details] [diff] [review]
reftest.list patch 348801->348809

That's what I get for doing this late at night... r=bzbarsky
Attachment #254535 - Flags: review?(dbaron) → review+
And checked in.
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED
Created attachment 254545 [details]
4 of the tests are failing

Now it looks like 4 of the tests are failing.  This is from the Linux test log.  The Windows log also showed 4 failures (didn't check that they were the same, though).
The first of the linux tests is an easy fix. It's an extra period at the end of the line "There should be no red".
incidentally, these are the same tests that are failing on windows.
Created attachment 254570 [details] [diff] [review]
Fix those

Yep.  The period, and three typos in the moving of onload handlers into inline script...  I _really_ shouldn't do tests at night.  :(

I checked this in.  With this, the tests pass as far as I can tell (by manual loading; running the actual test over remote X seems to be very unhappy).
You need to log in before you can comment on or make changes to this bug.