Bugzilla

Also, there are a few usability/papercut issues that I'm noticing, when testing with these patches applied (which I'm doing while looking into an implementation strategy for bug 1659005).  We can spin these issues off as one or more followups after this lands, too, but I'm not sure if it's better to address them up-front?)

STR:
 1. Apply both patches on this bug to mozilla-central.
 2. Start a print operation, and choose "Pages: Custom"
 3. Click the right edge of the "from" or "to" text field
 4. Press the backspace key (e.g. pretend you're just getting ready to type in the From/To value that you'd like, which means you have to clear the field first, of course)

ACTUAL RESULTS:
 - The red error text and border appears, chastising me about having chosen an invalid page range (simply due to having an empty text field)
 - Most of the settings/controls suddenly become disabled. The dialog now forces me to fix this field before it will let me do anything else, it seems.
 - Also, the error text occupies space and pushes content down out of the way (which feels jumpy)

EXPECTED RESULTS:
 - I would expect the error text to **not appear yet** when I've simply backspaced the number -- it should give me a "grace period" while I'm editing the text field. That's how form validation works normally, e.g. at `data:text/html,<input type="number" value="5" min="5" max="10"><input type="text">` which has a number field that only accepts values from 5-10 -- in this example, I can focus that number field, clear the value with my backspace key, and type in an invalid number, and the field doesn't change to highlight the error *until* I move focus outside of the field (e.g. by hitting `tab` or clicking the other field).  I would expect the From/To fields to behave the same way.
 - When the field is in an "invalid value" state, I would expect the rest of the print settings area to nonetheless remain useful.  E.g. maybe I started to edit my page range, and then realized I want to print in Landscape mode or choose a different page size -- it feels overly strict for Firefox to force me to fix my page range before it'll let me change those things (which pretty much invalidate my page range anyway)
- Furthermore, when the field is in an "invalid value" state, I would expect printing to still be possible -- we should just treat the invalid field as if it contained the most-extreme-acceptable value in that field (e.g. treat invalid input as "1" for the "from" field, and treat invalid input as "number-of-pages" for the "to" field).  We could either do this implicitly or explicitly (filling in the value for the user - why make them type it?)  In fact, this is what already happens if I click "Print using the system dialog" after having typed in a bogus value for part of the range.
 - Also: cosmetically, it feels odd for the error text to move things around in the dialog.  Ideally, we should warn the user in a way that doesn't push other settings/UI out of the way.

Also, there are a few usability/papercut issues that I'm noticing, when testing with these patches applied (which I'm doing while looking into an implementation strategy for bug 1659005).  We can spin these issues off as one or more followups after this lands, too, but I'm not sure if it's better to address them up-front?

STR:
 1. Apply both patches on this bug to mozilla-central.
 2. Start a print operation, and choose "Pages: Custom"
 3. Click the right edge of the "from" or "to" text field
 4. Press the backspace key (e.g. pretend you're just getting ready to type in the From/To value that you'd like, which means you have to clear the field first, of course)

ACTUAL RESULTS:
 - The red error text and border appears, chastising me about having chosen an invalid page range (simply due to having an empty text field)
 - Most of the settings/controls suddenly become disabled. The dialog now forces me to fix this field before it will let me do anything else, it seems.
 - Also, the error text occupies space and pushes content down out of the way (which feels jumpy)

EXPECTED RESULTS:
 - I would expect the error text to **not appear yet** when I've simply backspaced the number -- it should give me a "grace period" while I'm editing the text field. That's how form validation works normally, e.g. at `data:text/html,<input type="number" value="5" min="5" max="10"><input type="text">` which has a number field that only accepts values from 5-10 -- in this example, I can focus that number field, clear the value with my backspace key, and type in an invalid number, and the field doesn't change to highlight the error *until* I move focus outside of the field (e.g. by hitting `tab` or clicking the other field).  I would expect the From/To fields to behave the same way.
 - When the field is in an "invalid value" state, I would expect the rest of the print settings area to nonetheless remain useful.  E.g. maybe I started to edit my page range, and then realized I want to print in Landscape mode or choose a different page size -- it feels overly strict for Firefox to force me to fix my page range before it'll let me change those things (which pretty much invalidate my page range anyway)
- Furthermore, when the field is in an "invalid value" state, I would expect printing to still be possible -- we should just treat the invalid field as if it contained the most-extreme-acceptable value in that field (e.g. treat invalid input as "1" for the "from" field, and treat invalid input as "number-of-pages" for the "to" field).  We could either do this implicitly or explicitly (filling in the value for the user - why make them type it?)  In fact, this is what already happens if I click "Print using the system dialog" after having typed in a bogus value for part of the range.
 - Also: cosmetically, it feels odd for the error text to move things around in the dialog.  Ideally, we should warn the user in a way that doesn't push other settings/UI out of the way.