Last Comment Bug 644959 - Disabled button after async reload
: Disabled button after async reload
Status: VERIFIED FIXED
[bugday-2011-05-27]
: regression, testcase
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla6
Assigned To: Mounir Lamouri (:mounir)
:
: Andrew Overholt [:overholt]
Mentors:
Depends on:
Blocks: html5-parsing
  Show dependency treegraph
 
Reported: 2011-03-25 04:08 PDT by tza
Modified: 2013-03-28 09:58 PDT (History)
10 users (show)
mounir: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
wontfix
fixed
fixed


Attachments
Async loading - button disabled (3.66 KB, text/html)
2011-03-27 23:24 PDT, tza
no flags Details
Screenshot Firefox 3.6 - Firefox 4.0 (270.95 KB, image/png)
2011-05-02 23:05 PDT, tza
no flags Details
Patch v1 (5.84 KB, patch)
2011-05-30 04:46 PDT, Mounir Lamouri (:mounir)
hsivonen: review+
jst: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description tza 2011-03-25 04:08:18 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110303 Ubuntu/10.10 (maverick) Firefox/3.6.15
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0

Bug #592665 has a similar behaviour, but I have a different szenario.

I disable buttons via javascript before async form submit.
After the submit, the dom elements are cleaned up and dont exist anymore (document.getElementById('btn1') == null).
When I load the same form again (async), the html response does not contain the attribute disabled="disabled" on the buttons.

But when the form gets displayed again, the buttons are still disabled (the attribute is not set in the html response). Seems like it gets cached. 

Reproducible: Always

Steps to Reproduce:
1. Disable buttons via javascript before submit (async)
2. Affected dom elements are removed after submit
3. Reload form again (in the Html response, the buttons are enabled).
4. Buttons are disabled when displayed
Actual Results:  
Buttons still have attribute disabled="disabled"

Expected Results:  
The buttons should not be disabled.

Occurs on http only, but not on https.
If changing the form id before each request (eg. from test to test1) buttons wont be disabled.
Comment 1 Alex Lakatos[:AlexLakatos] 2011-03-25 07:38:33 PDT
Reporter, can you please provide a testcase? Thanks.
Comment 2 Ed Morley [:emorley] 2011-03-25 10:29:20 PDT
Did this occur with 3.6.x?
Comment 3 tza 2011-03-26 23:00:16 PDT
(In reply to comment #2)
> Did this occur with 3.6.x?

No, only happens with Firefox 4, works in 3.6.x.


(In reply to comment #1)
> Reporter, can you please provide a testcase? Thanks.

I will, after the weekend.
Comment 4 tza 2011-03-27 23:23:38 PDT
In the html testcase, I switched from an async request to YUI localdatasource to fake the async load. 

Same example with real async request can be found under: http://demo.silbergrau.com/ffdemo/

Open html file or the url above and then:
1) Open the dialog
2) Close dialog with button
3) Open dialog again => Button will be disabled (FF4)
Comment 5 tza 2011-03-27 23:24:33 PDT
Created attachment 522309 [details]
Async loading - button disabled
Comment 6 Alex Lakatos[:AlexLakatos] 2011-03-28 01:01:22 PDT
Confirmed on Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Comment 7 Rotan 2011-04-29 05:45:19 PDT
The following tiny test case also illustrates the issue clearly:

<!DOCTYPE html>
<html>
 <head><title>FF4 refresh bug</title></head>
 <body>
  <form>
   <input type="button" value="Disable" id="x" onclick="document.getElementById('x').disabled = true;"/>
  </form>
  <p>Click <b>Disable</b> then F5 to refresh. The button is <i>still</i> disabled!</p>
 </body>
</html>

Bug present in FF 4.0.1 (20110413222027) on Win 7 64bit
Comment 8 (mostly gone) XtC4UaLL [:xtc4uall] 2011-04-29 11:15:10 PDT
If someone can invest some Time, you can help by finding a Regression Range using http://harthur.github.com/mozregression/
Comment 9 Ed Morley [:emorley] 2011-05-02 16:02:34 PDT
I did a preliminary pass using mozregression, but the comment 5 and comment 7 testcases appear to have different regression ranges.

Reporter, please can you clarify exactly what is expected of the testcase in comment 5; Rotan please file comment 7 as a new bug and paste the link here - unless you can conform the regression ranges are the same (using the tool in comment 8).

Thanks :-)
Comment 10 tza 2011-05-02 23:05:33 PDT
Created attachment 529638 [details]
Screenshot Firefox 3.6 - Firefox 4.0

I would expect, that the button is Always enabled after async loading (looking at http://demo.silbergrau.com/ffdemo/). The screenshot shows difference between FF3.6 <-> FF4.0 after the first loading.

Looking at the response, there is no disabled flag for the button, but it is still disabled in FF4:
<button id="testButton" name="button" onclick="return disableAndRemove(this)">Disable and remove button</button>
Comment 11 Thomas Ahlblom 2011-05-27 13:48:14 PDT
Regression window of attachment 522309 [details] in comment 5:

Last good nightly: 2010-05-03 First bad nightly: 2010-05-04

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=83c887dff0da&tochange=d6bb0f9e9519

I also found that setting html5.parser.enable to false changes the current Nightly from a reproduced one to a WFM:
Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110527 Firefox/7.0a1

Thus it's probably bug 373864 in that regression range that makes the difference.
Comment 12 Henri Sivonen (:hsivonen) 2011-05-28 00:32:44 PDT
From the description, it seems that the form state is being loaded from the session history even when it shouldn't. What should the parser do here to tell the form state restoration mechanism that it's not wanted in this case?
Comment 13 Mounir Lamouri (:mounir) 2011-05-30 03:55:48 PDT
(In reply to comment #7)
> The following tiny test case also illustrates the issue clearly:
> 
> <!DOCTYPE html>
> <html>
>  <head><title>FF4 refresh bug</title></head>
>  <body>
>   <form>
>    <input type="button" value="Disable" id="x"
> onclick="document.getElementById('x').disabled = true;"/>
>   </form>
>   <p>Click <b>Disable</b> then F5 to refresh. The button is <i>still</i>
> disabled!</p>
>  </body>
> </html>
> 
> Bug present in FF 4.0.1 (20110413222027) on Win 7 64bit

This issue is different and very likely has tons of bugs filed in bugzilla.
Comment 14 Mounir Lamouri (:mounir) 2011-05-30 04:18:14 PDT
This is actually a bug in nsHTMLButtonElement.cpp. Taking this bug given that I have a patch fixing it locally. I will attach it as soon as I have a test.
Comment 15 Mounir Lamouri (:mounir) 2011-05-30 04:46:16 PDT
Created attachment 536049 [details] [diff] [review]
Patch v1

Fixing the issue and creating a test suite checking form restoration when created from a parser fragment for all form elements that have restoration enabled.
Comment 16 Mounir Lamouri (:mounir) 2011-05-30 04:50:07 PDT
I believe we shouldn't take this patch for FF5 but should we take it for FF6 given that it's a regression?
On the one hand, I would say it's an easy and simple fix. On the other hand, it doesn't seem to appears that often.
Comment 17 Olli Pettay [:smaug] 2011-05-30 06:04:27 PDT
Comment on attachment 536049 [details] [diff] [review]
Patch v1

I think Henri should look at this.
(I can review too, if needed.)
Comment 18 Henri Sivonen (:hsivonen) 2011-05-30 07:30:32 PDT
Comment on attachment 536049 [details] [diff] [review]
Patch v1

r=me.
Comment 19 Mounir Lamouri (:mounir) 2011-06-01 01:34:28 PDT
Pushed:
http://hg.mozilla.org/mozilla-central/rev/633b6373e876

tza, thank you for your bug report!
Comment 20 Mounir Lamouri (:mounir) 2011-06-01 01:35:49 PDT
Comment on attachment 536049 [details] [diff] [review]
Patch v1

See comment 16 for request reasons.
Comment 21 Johnny Stenback (:jst, jst@mozilla.com) 2011-06-01 11:37:17 PDT
Comment on attachment 536049 [details] [diff] [review]
Patch v1

Approved for Aurora 6.
Comment 22 Mounir Lamouri (:mounir) 2011-06-05 04:12:33 PDT
Pushed to mozilla-aurora:
http://hg.mozilla.org/releases/mozilla-aurora/rev/488cd9e29d65

This is going to be fixed in Firefox 6 then.

Marking wontfix for Firefox 5 given that it's not critical enough to push the fix to mozilla-beta IMO.
Comment 23 Trif Andrei-Alin[:AlinT] 2011-08-22 05:16:32 PDT
Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0

I followed the steps in comment 4 and it seems the issue was fixed.
Thanks.
Comment 24 Rotan 2011-11-17 04:54:05 PST
FF8 still exhibits the erroneous behaviour I described in comment 7.

I don't work on the moz code, but I know that those who do have some spare cycles to spend on this worthy task appreciate the benefit of a repeatable test. So please check the tiny piece of markup in comment 7 in your FF and see for yourselves.

I can't tell if this behaviour is related to the original issue, should be reported as a separate bug, or is simply another manifestation of a long-known problem. If it is related to the original issue, then bug 644959 has been closed prematurely.
Comment 25 tza 2011-11-17 05:29:36 PST
(In reply to Rotan from comment #24)
> FF8 still exhibits the erroneous behaviour I described in comment 7.

The issues I described in the comments 1 and 10 were fixed. So I guess Rotan's issue must be something else. Therefore you might consider reopening bug 644959.
Comment 26 Vadim 2013-03-28 09:23:21 PDT
I have this bug. Situation:
We have button without attr disabled. Click this button start some routine and JS set attr disabled='disabled' to this button with jQuery 'button' plagin, which in Bootstrap 2. And after all routine finished, 'button' plugin reset this button and remove attr disabled. If we reload page before button reseted and attr disabled don't removed in firefox 19.0.2 that button will have attr disabled='', but behaviour like disabled='disabled' and any action not help: reload page, clean cash, etc...only new tab or reload firefox help.

In chrome/safari that good, i think that ffox cached this state, but clean cache in settings this not help.

Its situation rare, but possible, that should fixed. Thanks, with regards, Vadim.
Comment 27 Vadim 2013-03-28 09:24:22 PDT
forget, Mac OS X 10.8.2

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