If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

cannot log in to website with Firefox v. 12.0




6 years ago
4 years ago


(Reporter: Paul Warner, Assigned: smaug)


12 Branch
Windows 7

Firefox Tracking Flags

(firefox12+, firefox13+, firefox14-, firefox15-)



(3 attachments)



6 years ago
Created attachment 618584 [details]

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

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.
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

6 years ago
(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

6 years ago
Regression window(m-c)
Cannot reproduce:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120126 Firefox/12.0a1 ID:20120126093130
Can reproduce
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120126 Firefox/12.0a1 ID:20120126151450

Regression window(m-i)
Cannot reproduce:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120126 Firefox/12.0a1 ID:20120126000751
Can reproduce
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120125 Firefox/12.0a1 ID:20120126020351

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

Comment 4

6 years ago
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

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


6 years ago
tracking-firefox12: --- → ?
tracking-firefox13: --- → ?
tracking-firefox14: --- → ?
tracking-firefox15: --- → ?
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);
(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

6 years ago
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

6 years ago
(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

6 years ago
Created attachment 618701 [details] [diff] [review]
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

6 years ago
Tryserver builds will be here http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/opettay@mozilla.com-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

6 years ago
Created attachment 618719 [details] [diff] [review]
for beta


6 years ago
Attachment #618701 - Flags: review?(ajvincent)
Comment on attachment 618701 [details] [diff] [review]
allow timeout with sync XHR

> nsXMLHttpRequest::SetTimeout(uint32_t aTimeout, nsresult& aRv)
> {
>-      HasOrHasHadOwner()) {

I see removing the sync check, but the unsent check?  Or is that a subtle bug that I introduced?
Attachment #618701 - Flags: review?(ajvincent) → review+
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

6 years ago
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?
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

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

Comment 18

6 years ago
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!
Tracking for all versions, though this will likely be first fixed in FF13 (or left unfixed) depending on the number of affected websites.
tracking-firefox12: ? → +
tracking-firefox13: ? → +
tracking-firefox14: ? → +
tracking-firefox15: ? → +
Ever confirmed: true
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.
Component: Untriaged → DOM: Mozilla Extensions
Product: Firefox → Core
QA Contact: untriaged → general


6 years ago
Assignee: nobody → bugs
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

6 years ago
That would be a horrible API.
Well sync XHR is already horrible ... :-)

Comment 24

6 years ago
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
I prepared the patches in case there were many bug reports, but I have seen only this one.
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.
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

6 years ago
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

6 years ago
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

6 years ago
We should probably warn whenever sync XHR is used in window context.
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

5 years ago
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

5 years ago
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

5 years ago
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?
We've now shipped past FF12, without this becoming an explosive issue. Untracking.
tracking-firefox14: + → -
tracking-firefox15: + → -
FF15 has recently shipped, and there hasn't been much fallout from timeouts for sync XHR.  Shall we mark this INVALID?

Comment 36

5 years ago
I think this bug can be closed now.
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.