Closed
Bug 749098
Opened 12 years ago
Closed 11 years ago
cannot log in to website with Firefox v. 12.0
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: paulwwarner, Assigned: smaug)
References
Details
Attachments
(3 files)
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
WeirdAl
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review |
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•12 years ago
|
||
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.
Reporter | ||
Comment 2•12 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•12 years ago
|
||
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.
Blocks: xhr-timeout
Assignee | ||
Comment 4•12 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.
Assignee | ||
Comment 5•12 years ago
|
||
Looks like http://code.google.com/p/ext-basex/issues/detail?id=7
Assignee | ||
Updated•12 years ago
|
tracking-firefox12:
--- → ?
tracking-firefox13:
--- → ?
tracking-firefox14:
--- → ?
tracking-firefox15:
--- → ?
Comment 6•12 years ago
|
||
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•12 years ago
|
||
(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?
Assignee | ||
Comment 8•12 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
Reporter | ||
Comment 9•12 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.
Assignee | ||
Comment 10•12 years ago
|
||
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)
Assignee | ||
Comment 11•12 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.
Assignee | ||
Comment 12•12 years ago
|
||
Assignee | ||
Updated•12 years ago
|
Attachment #618701 -
Flags: review?(ajvincent)
Comment 13•12 years ago
|
||
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?
Attachment #618701 -
Flags: review?(ajvincent) → review+
Comment 14•12 years ago
|
||
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...
Reporter | ||
Comment 15•12 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?
Comment 16•12 years ago
|
||
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.
Reporter | ||
Comment 17•12 years ago
|
||
Thanks, Matthias, for the reply. I have deleted the firefoxtest user. If someone needs login access for testing, please let me know.
Reporter | ||
Comment 18•12 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!
Comment 19•12 years ago
|
||
Tracking for all versions, though this will likely be first fixed in FF13 (or left unfixed) depending on the number of affected websites.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 20•12 years ago
|
||
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
Updated•12 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).
Assignee | ||
Comment 22•12 years ago
|
||
That would be a horrible API.
Well sync XHR is already horrible ... :-)
Assignee | ||
Comment 24•12 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 implementation. I prepared the patches in case there were many bug reports, but I have seen only this one.
Comment 25•12 years ago
|
||
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•12 years ago
|
||
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•12 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.
Assignee | ||
Comment 28•12 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.
Assignee | ||
Comment 29•12 years ago
|
||
We should probably warn whenever sync XHR is used in window context.
Comment 30•12 years ago
|
||
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.
Assignee | ||
Comment 31•12 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.
Reporter | ||
Comment 32•12 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.
Assignee | ||
Comment 33•12 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?
Comment 34•12 years ago
|
||
We've now shipped past FF12, without this becoming an explosive issue. Untracking.
Comment 35•12 years ago
|
||
FF15 has recently shipped, and there hasn't been much fallout from timeouts for sync XHR. Shall we mark this INVALID?
Comment 36•12 years ago
|
||
I think this bug can be closed now.
Updated•12 years ago
|
Component: DOM: Mozilla Extensions → DOM
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•