644144 - Multipage form using .Net Multiview and AJAX issues.

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[c.tess]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0

There are two happening, but I think the cause is the same. On the URL I provided my university has a multipaged form, it has been working for a long time in all browsers. In the release of FF4 this form no longer works as it should. 
1 - The AJAX functionality that should keep the page from refreshing when going to the next page in the form is not working. The page is refreshing entirely.
2 - Upon submitting the form the page posts to an aspx page, and then redirects. This is also no longer happening. 

I think the issue is based around the use of the .Net multiview and AJAX. There is other AJAX functionality that works on the page just fine. You can fill out the form and go through the pages and you will see the page refresh each time.

These issues did not happen in the FF4 beta releases.

Reproducible: Always

Steps to Reproduce:
1.Browse to the form
2.Enter information on page 1, use last name "test".
3.Hit the next button, the page will refresh, it should not. You can verify this in Firefox 3.6 or lower, as well as any other browser.
4.Complete all pages of the form.
5.Click the submit button on the summary page.
6.The page will refresh and the buttons will be gone. This should not happen, you should be reidrected to a thank you page. Again any other browser will demonstrate this working just fine.
Actual Results:  
1 - The page was refreshed each time in the form. 
2 - The form will not redirect to a thank you page.

Expected Results:  
1 - The page should not be refreshing each time the next button is clicked.
2 - The form should redirect on submit.

I don't know exactly what changed, but something with the handling of AJAX requests seems to have changed. Again this form continued to work in the beta releases, I did not test in the RC so I cannot confirm it worked there at all. This is not a bug in our form, it continues to work in every other browser, including the FF4 beta, and anything from 3.6 or earlier.

Comment 1

[Ed Morley [:emorley]]

Confirmed with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110322 Firefox/4.0b13pre ID:20110322030409

Would you be able to try and find the regression range:
http://harthur.github.com/mozregression/

Comment 2

[Ed Morley [:emorley]]

Took ages, after I managed to bungle the first bisection by entering b instead of g for one stage (and the form required fields make it quite a pain to fill out), but here it is...

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

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

After all that surprise surprise:
Bug 373864 - Enable the HTML5 parser by default
(Amongst others, but imagine we have a definite winner)

Reporter, can you try going to about:config in Fx4 final and setting html5.parser.enable to false, reloading the page and seeing if the issue stops occurring please. (Just to confirm it definitely is the cause)

Am going to move provisionally to Core::Parser for now, but presume it may end up in TE.

Comment 3

[c.tess]

I just gave the form a test after making the change you suggested and it worked
just fine. 

Thanks for such a fast response on this. I did not expect even an initial
response today, let alone finding the cause.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Henri, sounds like this is in your bucket...

Comment 5

[Henri Sivonen (:hsivonen)]

Looks like the site works with Chrome's UA string.

(In reply to comment #0)
> This is not a bug in our form, it continues to work in every other browser,
> including the FF4 beta, and anything from 3.6 or earlier.

Seems like a UA sniffing issue that relies on the difference between the beta UA string and the final UA string.

Comment 6

[c.tess]

Is there an update as to if/when this bug will be fixed in the browser, and when that browser might be released?

Comment 7

[Chris Lawson (gone)]

This is not a browser bug; see comment 5.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Indeed.  This is a bug in the site, which is doing browser sniffing and getting it wrong.  Sorry comment 5 didn't make that more clear; this bug is assigned to the "Tech Evangelism" product now, which means "contact the site and get them to fix it"...

If you know who should be contacted about the page, could you please do it?

Comment 9

[c.tess]

Sure, it's my page. I'm curious as to what you mean by browser sniffing. We do some cookie and refferer code, but that's about it. This app works fine in every other browser as well. 

Early on when I logged this I was asked to change the setting html5.parser.enable to false which did fix the issue. Doesn't that show the issue is with the browser and not the page?

Comment 10

[Chris Lawson (gone)]

I suspect this line in JQuery:

a=/(webkit)[ \/]([\w.]+)/.exec(a)||/(opera)(?:.*version)?[ \/]([\w.]+)/.exec(a)||/(msie) ([\w.]+)/.exec(a)||!/compatible/.test(a)&&/(mozilla)(?:.*? rv:([\w.]+))?/.exec(a)||[];

is choking on the new UA string format introduced in Firefox 4 final.

(That file is here: <http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js>.)

Comment 11

[Chris Lawson (gone)]

JQuery's current release is 1.6.1, by the way, according to jquery.com, so it might be a simple matter of updating the version of JQuery you're using.

Comment 12

[c.tess]

Well updating to 1.6.1 did not fix any issues. If this is an issue with jQuery not being able to handle a new string format introduced in Firefox 4, then what do I need to tell jQuery so I can log a bug with them? This issue is not something entirely under my control. I am not going to get into rewriting jQuery because the FF team changed a string.

Comment 13

[Boris Zbarsky [:bzbarsky]]

> I'm curious as to what you mean by browser sniffing.

See comment 5: if Firefox claims to be Chrome in the UA string, with no other changes on our side, your site suddenly starts working.  That means the site is doing different things based on the UA string _somehow_.  I'm guessing that Chris found the exact part of your site that's doing that.

> Doesn't that show the issue is with the browser and not the page?

It shows that the page assumes the browser uses the old parsing algorithm for Firefox instead of the one the HTML5 spec calls for, while assuming the HTML5 parsing algorithm for Chrome.  Firefox 4 implements the HTML5 parsing algorithm, unless you force it off by flipping that pref.  Again, the page is doing different things in different browsers based on some sort of sniffing, likely inside jquery...

Comment 14

[Boris Zbarsky [:bzbarsky]]

Reporting the issue to jquery may be a good idea, but in general jquery does work with Fx4.  So I guess the question is what code is running in this case and why it's messing up.  Which jquery code do you call into when the submit button is clicked?  What does that part of your page source look like?

Comment 15

[c.tess]

On submit we use the jQuery validate plugin, but that plugin is working on every page of this form, including the last page. The real problem isn't the submit itself, it is that the final redirect after submit does not work at all. Again this all works in every browser, including the betas and release candidates for Firefox. 

If the issue was with jQuery and what happens on submit, wouldn't the submit action on each page of the form fail as well? Wouldn't the form itself fail to submit at the end (which it does not fail)?

Comment 16

[Boris Zbarsky [:bzbarsky]]

OK.  Do you know what's supposed to trigger the redirect after the submit?

Also, isn't the page refresh that shouldn't be happening a problem as well?

> Again this all works in every browser, including the betas and release
> candidates for Firefox. 

It does?  The second release candidate of Firefox 4 was bit-for-bit identical to the final release... The first one was very close, with no changes between the two that should have affected this.  The betas did have a different UA string format in some cases, but I looked carefully at the regexp Chris posted and it doesn't seem to be a problem.  It's also only used if you use jQuery.browser stuff.

Can you point me to the validate plugin you're using?

Comment 17

[Karl Dubost💡 :karlcow]

Tested the form and everything worked as expected in Firefox 32.0.2