749098 - cannot log in to website with Firefox v. 12.0

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Paul Warner]

Attachment: firefox-general-info-for-bug-report.txt

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19

Steps to reproduce:

I upgraded to Firefox v. 12.0 from v. 11.


Actual results:

Now I can no longer log in to my website: http://hudesktopdevel.hucompute.org/desktop.jsp.  I simply get bounced back to the login page.  I have gone through all the steps in https://support.mozilla.org/en-US/kb/Cannot%20log%20in%20to%20websites?e=es&as=aaq but to no avail. Still can't log in. There was no problem with the previous version of Firefox. The server log shows only that an attempt to log in has been made, but not completed. There are no errors.

I turned off all the extensions and plugins, according to the instructions from the Firefox support page listed above.  But to find out if Firebug had anything to say, I turned it back on, and got these two error messages:
1. Ungültige URI. Laden der Medienressource fehlgeschlagen. (Invalid URI.  Loading the resource failed)
2. getAttributeNodeNS() sollte nicht mehr verwendet werden. Verwenden Sie stattdessen getAttributeNS(). (getAttributeNodeNS() should not be used anymore.  Use getAttributeNS() instead.  --I believe this is an error message from Extjs, which we use extensively in this application --pw)

Windows 7 Professional v. 6.1 (Build 7601: Service Pack 1) Firefox 12
Sites Affected
http://hudesktopdevel.hucompute.org/index.jsp




Expected results:

should be able to log in.  Our users have been told to use Firefox or Chrome for our website, so those using Firefox 12 will not be able to do their work.

Comment 1

[Matthias Versen [:Matti]]

Is there a way to test this for us ?
That would it make possible to search for a regression range.
You would have to do that if no public test is possible.

Comment 2

[Paul Warner]

(In reply to Matthias Versen (Matti) from comment #1)
> Is there a way to test this for us ?
> That would it make possible to search for a regression range.
> You would have to do that if no public test is possible.

Ok, I have created a test account.  User: firefoxtest Pwd: Wodeni87
This is a development site; please be careful.  Thanks for looking at this problem!

Comment 3

[Alice0775 White]

Regression window(m-c)
Cannot reproduce:
http://hg.mozilla.org/mozilla-central/rev/7cdb5f5d38c6
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120126 Firefox/12.0a1 ID:20120126093130
Can reproduce
http://hg.mozilla.org/mozilla-central/rev/a82c9700c673
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120126 Firefox/12.0a1 ID:20120126151450
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7cdb5f5d38c6&tochange=a82c9700c673


Regression window(m-i)
Cannot reproduce:
http://hg.mozilla.org/integration/mozilla-inbound/rev/5aadcbb1dfce
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120126 Firefox/12.0a1 ID:20120126000751
Can reproduce
http://hg.mozilla.org/integration/mozilla-inbound/rev/22797d62aa14
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120125 Firefox/12.0a1 ID:20120126020351
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5aadcbb1dfce&tochange=22797d62aa14

Triggered by:
22797d62aa14	Alex Vincent — Implement XMLHttpRequest.timeout support. Bug 525816, r=smaug, sr=sicking.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

If I read the JS code correctly, the page tries to use XHR.timeout on sync XHR.
That is allowed per XHR2 spec.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Looks like http://code.google.com/p/ext-basex/issues/detail?id=7

Comment 6

[Masatoshi Kimura [:emk]]

Nightly makes it much easier to spot the offending code thanks to bug 743575 :)
Warning: Use of XMLHttpRequest's timeout attribute is not supported in the synchronous mode in window context.
Source File: http://hudesktopdevel.hucompute.org/modules/basex/ext-basex.js
Line: 1010
>                        ('timeout' in r) && (r.timeout = callback.timeout);
It should be something like:
options.async && ('timeout' in r) && (r.timeout = callback.timeout);

Comment 7

[Masatoshi Kimura [:emk]]

(In reply to Olli Pettay [:smaug] from comment #4)
> If I read the JS code correctly, the page tries to use XHR.timeout on sync
> XHR.
> That is allowed per XHR2 spec.
*Not* allowed per XHR2 spec?

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Oops, right. Not allowed :)

(In reply to Paul Warner from comment #2)
> Ok, I have created a test account.  User: firefoxtest Pwd: Wodeni87
doesn't seem to work, no matter which browser I use

Comment 9

[Paul Warner]

(In reply to Olli Pettay [:smaug] from comment #8)
> Oops, right. Not allowed :)
> 
> (In reply to Paul Warner from comment #2)
> > Ok, I have created a test account.  User: firefoxtest Pwd: Wodeni87
> doesn't seem to work, no matter which browser I use

Someone left the devel server in a broken state when they went home today.  However, the error appears after you get past the login for Opera and Chrome.  In Firefox, you bounce directly back to the login after logging in.  If this is a show stopper, I will look into it and try to get rid of the error.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Attachment: allow timeout with sync XHR

Just in case we need to change the behavior (which I *really* don't want to do.
Sync XHR in window context is evil! and we shouldn't support any new features on it)

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Tryserver builds will be here http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-a8e0db72ea99/
But really, as of now I don't expect Firefox to change behavior.
It is the script library which shouldn't expect behavior against the spec.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Attachment: for beta

Comment 13

[Alex Vincent [:WeirdAl]]

Comment on attachment 618701 [details] [diff] [review]
allow timeout with sync XHR

> nsXMLHttpRequest::SetTimeout(uint32_t aTimeout, nsresult& aRv)
> {
>-  if (!(mState & (XML_HTTP_REQUEST_ASYNC | XML_HTTP_REQUEST_UNSENT)) &&
>-      HasOrHasHadOwner()) {

I see removing the sync check, but the unsent check?  Or is that a subtle bug that I introduced?

Comment 14

[Alex Vincent [:WeirdAl]]

FWIW, I'm not really happy about this idea either, as I am beholden to the spec (even though the spec may change).  Sync XHR really is a bad idea for main-thread code, and adding in patches that are lenient towards sync XHR just doesn't seem right.

Olli, on the patch you submitted: there's a bug to disable sync XHR in chrome... if we can determine that it's a chrome sync request with timeout, I'd have no mercy on that.  Chrome code devs are supposed to be more aware. :)

If this isn't that widespread, then I'd vote against taking this.  It's really unreasonable for a webdev or library to assume browsers will never change, will never implement missing features that the libraries try to make up for. In particular, we do have public betas and Aurora builds that were available with this, and it was known for three months...

Comment 15

[Paul Warner]

I would like to alter the test user, and email it directly to the people working on this bug.  The bug has now become more public, and anyone can see the account here.  Is it possible/ok to make the account information only available to the developers here?

Comment 16

[Matthias Versen [:Matti]]

I think it's ok to close the testaccount now. A Developer who needs access can ask you directly for the Account information via email.

Comment 17

[Paul Warner]

Thanks, Matthias, for the reply.  I have deleted the firefoxtest user.  If someone needs login access for testing, please let me know.

Comment 18

[Paul Warner]

I have taken the code change suggested by Masatoshi Kimura above, and inserted it into our ext-basex.js code.  And now login works for our application on Firefox 12! Perhaps this can be the suggested course of action for Extjs 3 users who have login problems with Firefox 12.  Thanks very much for your attention to and work on this problem!

Comment 19

[Alex Keybl [:akeybl]]

Tracking for all versions, though this will likely be first fixed in FF13 (or left unfixed) depending on the number of affected websites.

Comment 20

[Alex Keybl [:akeybl]]

Sending over to Olli, since we should try to resolve for FF13, and regressing bug 525816 was reviewed by him. If there's reason to believe that this is won't be a problem for other sites, please make the case for untracking.

Comment 21

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Can we just ignore the timeout for sync XHR instead of throwing?  That seems like the best course of action to me (and is what we were doing before we implemented xhr.timeout).

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

That would be a horrible API.

Comment 23

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Well sync XHR is already horrible ... :-)

Comment 24

[Olli Pettay [:smaug][[e-mail]]]

And we're trying to make web devs to use it less... so throwing an exception sounds the best
we can do. *If*  syncXHR.timeout breaks many sites, we need to get the spec changed and change our
implementation.
I prepared the patches in case there were many bug reports, but I have seen only this one.

Comment 25

[Alex Vincent [:WeirdAl]]

It's also worth mentioning we're the first ones to implement timeout support - Chrome didn't have it, nor did Opera, nor did IE or Safari.  So we're setting a precedent here by implementing the specification first.  It would be bad for the Web to reverse our decision based on a very small sample size.

This was going to happen to somebody sooner or later, and I strongly support keeping our existing behavior unless there was widespread breakage.

Comment 26

[Masatoshi Kimura [:emk]]

Actually IE8+ supports .timeout (even on sync XHR!)
So if a site expect .timeout will work like on IE, it will break.
That said, I also support keeping the current behavior unless many actual sites are broken.

Comment 27

[Florian Bender]

Can we have it fail silently and write a warning to the console (compromise between failing silently and throwing)? Though, personally, I'd like to see it throw.

Comment 28

[Olli Pettay [:smaug][[e-mail]]]

We do what the spec says.

Silently failing doesn't sound a good option to me. Web pages would be expecting the
timeout works with sync XHR.

Comment 29

[Olli Pettay [:smaug][[e-mail]]]

We should probably warn whenever sync XHR is used in window context.

Comment 30

[Alex Keybl [:akeybl]]

Is there any way we can reason about the number of affected sites on the internet without waiting for feedback from our users? For instance, we could grep the web with blekko if we have something to grep for.

Comment 31

[Olli Pettay [:smaug][[e-mail]]]

It is hard to know how libraries use XHR and whether they use .timeout on those objects.

Btw, ext-basex project doesn't look active. Last commit was Jan 6, 2011, and last release May 2010.

Comment 32

[Paul Warner]

ext-basex is part of extjs 3.  extjs has moved on to v. 4, which does not include ext-basex.  I do not know if ext 4 continues to use XHR with .timeout anywhere in its code...

I know that Zend website users are also affected.  If one could somehow figure out how many websites are using extjs 3 or Zend, it would be a start.

Comment 33

[Olli Pettay [:smaug][[e-mail]]]

well, the problem happens only if you use synchronous XHR *and* .timeout.
So counting extjs3+ext-basex or Zend websites wouldn't give too much information.

Also, I'm surprised to hear that Zend has had problems. Has anyone seen a bug report about it?

Comment 34

[Alex Keybl [:akeybl]]

We've now shipped past FF12, without this becoming an explosive issue. Untracking.

Comment 35

[Alex Vincent [:WeirdAl]]

FF15 has recently shipped, and there hasn't been much fallout from timeouts for sync XHR.  Shall we mark this INVALID?

Comment 36

[Florian Bender]

I think this bug can be closed now.