Closed
Bug 907657
Opened 11 years ago
Closed 11 years ago
Firefox24 hangs if synchronous XMLHttpRequest was sent inside onkeydown
Categories
(Core :: Widget: Win32, defect)
Tracking
()
VERIFIED
FIXED
mozilla26
People
(Reporter: tigeral, Assigned: masayuki)
References
(Depends on 1 open bug)
Details
(Keywords: hang, regression, testcase)
Attachments
(3 files, 2 obsolete files)
331 bytes,
text/html
|
Details | |
7.30 KB,
patch
|
jimm
:
review+
bajaj
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
7.68 KB,
patch
|
jimm
:
review+
bajaj
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release) Build ID: 20130815180504 Steps to reproduce: 1. create a simple html page with a synchronous XMLHttpRequest inside onkeydown listener and place this file to some web server in order to send Ajax request without cross-domain restrictions. Just like in sample below: <html> <head> <script type="text/javascript"> function onKeyDown() { var xmlHttp = new XMLHttpRequest(); xmlHttp.open("GET","http://localhost:8080/1.txt",false); xmlHttp.send(); } </script> </head> <body> <input type="text" onkeydown="onKeyDown();"/> </body> </html> 2. open this page with a Firefox browser ver. 24 (this issue didn't reproduced in FF23) 3. set focus to input field and press any key 4. now Firefox hangs Actual results: Firefox hangs, so it couldn't work and can be only closed by Windows task manager Expected results: Firefox should work as usual
Reporter | ||
Updated•11 years ago
|
See Also: → 907278
Whiteboard: Firefox24 onkeydown synchronous XMLHttpRequest
Updated•11 years ago
|
Component: Untriaged → XML
Product: Firefox → Core
Comment 1•11 years ago
|
||
Not sure where this should go, so leaving it on General.
Component: XML → General
Comment 2•11 years ago
|
||
If you're not sure where it should go, Firefox::Untriaged is probably best. XMLHttpRequest tend to belong in Core::DOM, though.
Component: General → DOM
Whiteboard: Firefox24 onkeydown synchronous XMLHttpRequest
Comment 3•11 years ago
|
||
(In reply to :Ms2ger from comment #2) > If you're not sure where it should go, Firefox::Untriaged is probably best. > XMLHttpRequest tend to belong in Core::DOM, though. Thanks. I moved it here because it gave it more chances to get into the right component, since we with Firefox didn't know for sure where to move it.
Updated•11 years ago
|
Flags: needinfo?(bugs)
Updated•11 years ago
|
Flags: needinfo?(bugs)
Keywords: regressionwindow-wanted
Comment 4•11 years ago
|
||
Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/2372a5ade39f Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130529 Firefox/24.0 ID:20130529072431 Bad: http://hg.mozilla.org/mozilla-central/rev/8d85de779506 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130529 Firefox/24.0 ID:20130529072533 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2372a5ade39f&tochange=8d85de779506 Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/0d52ae944c00 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130528 Firefox/24.0 ID:20130528212231 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/57461a161f93 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130528 Firefox/24.0 ID:20130528233532 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0d52ae944c00&tochange=57461a161f93 Regressed by: Bug 855975
Blocks: 855975
status-firefox23:
--- → unaffected
tracking-firefox24:
--- → ?
tracking-firefox25:
--- → ?
tracking-firefox26:
--- → ?
Keywords: regressionwindow-wanted → regression
Updated•11 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 5•11 years ago
|
||
Hmm, it's very odd. The bug tried to just move the old code to new place... I'll investigate this ASAP.
Keywords: hang
Assignee | ||
Comment 6•11 years ago
|
||
Assignee | ||
Comment 7•11 years ago
|
||
The regression point is this changeset: https://hg.mozilla.org/mozilla-central/rev/fef076fed8ab Calling GetMessage() causes deadlock. I'm still not sure the reason.
Assignee | ||
Comment 8•11 years ago
|
||
> 3.34 - MSG msg;
> 3.35 - BOOL gotMsg = aFakeCharMessage ||
> 3.36 - WinUtils::PeekMessage(&msg, mWnd, WM_KEYFIRST, WM_KEYLAST,
> 3.37 - PM_NOREMOVE | PM_NOYIELD);
> 3.38 - if (gotMsg &&
> 3.39 - (aFakeCharMessage || msg.message == WM_CHAR ||
> 3.40 - msg.message == WM_SYSCHAR || msg.message == WM_DEADCHAR)) {
> 3.41 + inputtingChars, extraFlags);
> 3.42 + }
> 3.43 +
> 3.44 + if (nativeKey.IsFollowedByCharMessage()) {
> 3.45 + const MSG& msg = nativeKey.RemoveFollowingCharMessage();
Ah, I see.
The PeekMessage() returns false. Therefore, it's not into the following if block. Then, GetMessage() isn't called in this situation. Although, it's really a bug.
Assignee | ||
Comment 9•11 years ago
|
||
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Assignee | ||
Comment 10•11 years ago
|
||
aurora: https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=1d29944eb2a8 m-c: https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=8a132839b87c
Assignee | ||
Comment 11•11 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=b33e8c92aba7
Assignee | ||
Comment 12•11 years ago
|
||
Although, I don't understand well the native event loop mechanism. However, according to the log of debugger, during dispatching keydown event, following WM_CHAR message is received via wndproc. Therefore, stored WM_CHAR message has been removed when dispatching keydown is finished. Therefore, GetMessage() which is called from DispatchKeyPressEventForFollowingCharMessage() don't return immediately because there are no WM_CHAR message which was stored in mCharMsg. I think that next message shouldn't be fetched during keydown event. But in this bug, we should fix only the regression for safer fix.
Assignee | ||
Updated•11 years ago
|
Component: DOM → Widget: Win32
Assignee | ||
Updated•11 years ago
|
Assignee | ||
Comment 13•11 years ago
|
||
The stack at the nested WM_CHAR message received:
>> xul.dll!mozilla::widget::NativeKey::HandleCharMessage(const tagMSG & aCharMsg, bool * aEventDispatched) Line 932 C++
> xul.dll!nsWindow::ProcessCharMessage(const tagMSG & aMsg, bool * aEventDispatched) Line 5630 + 0xa bytes C++
> xul.dll!nsWindow::ProcessMessage(unsigned int msg, unsigned int & wParam, long & lParam, long * aRetValue) Line 4775 + 0xf bytes C++
> xul.dll!nsWindow::WindowProcInternal(HWND__ * hWnd, unsigned int msg, unsigned int wParam, long lParam) Line 4349 + 0x17 bytes C++
> xul.dll!CallWindowProcCrashProtected(long (HWND__ *, unsigned int, unsigned int, long)* wndProc, HWND__ * hWnd, unsigned int msg, unsigned int wParam, long lParam) Line 32 + 0xf bytes C++
> xul.dll!nsWindow::WindowProc(HWND__ * hWnd, unsigned int msg, unsigned int wParam, long lParam) Line 4301 + 0x14 bytes C++
> user32.dll!771977d8()
> [Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]
> user32.dll!771978cb()
> user32.dll!7719787a()
> user32.dll!7719899d()
> user32.dll!77198a66()
> xul.dll!nsAppShell::ProcessNextNativeEvent(bool mayWait) Line 223 C++
> xul.dll!nsBaseAppShell::DoProcessNextNativeEvent(bool mayWait, unsigned int recursionDepth) Line 137 + 0x16 bytes C++
> xul.dll!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr, bool mayWait, unsigned int recursionDepth) Line 278 C++
> xul.dll!nsThread::ProcessNextEvent(bool mayWait, bool * result) Line 598 C++
> xul.dll!NS_ProcessNextEvent(nsIThread * thread, bool mayWait) Line 238 + 0xd bytes C++
> xul.dll!nsXMLHttpRequest::Send(nsIVariant * aVariant, const mozilla::dom::Nullable<nsXMLHttpRequest::RequestBody> & aBody) Line 2908 + 0xd bytes C++
> xul.dll!nsXMLHttpRequest::Send(mozilla::ErrorResult & aRv) Line 352 + 0x13 bytes C++
> xul.dll!mozilla::dom::XMLHttpRequestBinding::send(JSContext * cx, JS::Handle<JSObject *> obj, nsXMLHttpRequest * self, const JSJitMethodCallArgs & args) Line 490 C++
> xul.dll!mozilla::dom::XMLHttpRequestBinding::genericMethod(JSContext * cx, unsigned int argc, JS::Value * vp) Line 1167 + 0x20 bytes C++
> mozjs.dll!js::CallJSNative(JSContext * cx, bool (JSContext *, unsigned int, JS::Value *)* native, const JS::CallArgs & args) Line 219 + 0xf bytes C++
> mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) Line 489 + 0x10 bytes C++
> mozjs.dll!Interpret(JSContext * cx, js::RunState & state) Line 2484 + 0x27 bytes C++
> mozjs.dll!js::RunScript(JSContext * cx, js::RunState & state) Line 446 + 0x7 bytes C++
> mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) Line 508 + 0xa bytes C++
> mozjs.dll!js::Invoke(JSContext * cx, const JS::Value & thisv, const JS::Value & fval, unsigned int argc, JS::Value * argv, JS::MutableHandle<JS::Value> rval) Line 539 + 0x27 bytes C++
> mozjs.dll!JS_CallFunctionValue(JSContext * cx, JSObject * objArg, JS::Value fval, unsigned int argc, JS::Value * argv, JS::Value * rval) Line 5416 + 0x35 bytes C++
> xul.dll!mozilla::dom::EventHandlerNonNull::Call(JSContext * cx, JS::Handle<JSObject *> aThisObj, nsDOMEvent & event, mozilla::ErrorResult & aRv) Line 38 + 0x2d bytes C++
> xul.dll!mozilla::dom::EventHandlerNonNull::Call<nsISupports *>(nsISupports * const & thisObj, nsDOMEvent & event, mozilla::ErrorResult & aRv, mozilla::dom::CallbackObject::ExceptionHandling aExceptionHandling) Line 59 + 0x21 bytes C++
> xul.dll!nsJSEventListener::HandleEvent(nsIDOMEvent * aEvent) Line 249 C++
> xul.dll!nsEventListenerManager::HandleEventSubType(nsListenerStruct * aListenerStruct, const mozilla::dom::CallbackObjectHolder<mozilla::dom::EventListener,nsIDOMEventListener> & aListener, nsIDOMEvent * aDOMEvent, mozilla::dom::EventTarget * aCurrentTarget, nsCxPusher * aPusher) Line 977 + 0x10 bytes C++
> xul.dll!nsEventListenerManager::HandleEventInternal(nsPresContext * aPresContext, nsEvent * aEvent, nsIDOMEvent * * aDOMEvent, mozilla::dom::EventTarget * aCurrentTarget, nsEventStatus * aEventStatus, nsCxPusher * aPusher) Line 1049 + 0x12 bytes C++
> xul.dll!nsEventListenerManager::HandleEvent(nsPresContext * aPresContext, nsEvent * aEvent, nsIDOMEvent * * aDOMEvent, mozilla::dom::EventTarget * aCurrentTarget, nsEventStatus * aEventStatus, nsCxPusher * aPusher) Line 330 + 0x15 bytes C++
> xul.dll!nsEventTargetChainItem::HandleEvent(nsEventChainPostVisitor & aVisitor, ELMCreationDetector & aCd, nsCxPusher * aPusher) Line 188 C++
> xul.dll!nsEventTargetChainItem::HandleEventTargetChain(nsTArray<nsEventTargetChainItem> & aChain, nsEventChainPostVisitor & aVisitor, nsDispatchingCallback * aCallback, ELMCreationDetector & aCd, nsCxPusher * aPusher) Line 284 C++
> xul.dll!nsEventDispatcher::Dispatch(nsISupports * aTarget, nsPresContext * aPresContext, nsEvent * aEvent, nsIDOMEvent * aDOMEvent, nsEventStatus * aEventStatus, nsDispatchingCallback * aCallback, nsCOMArray<mozilla::dom::EventTarget> * aTargets) Line 585 C++
> xul.dll!PresShell::HandleEventInternal(nsEvent * aEvent, nsEventStatus * aStatus) Line 6861 + 0x14 bytes C++
> xul.dll!PresShell::HandleEvent(nsIFrame * aFrame, nsGUIEvent * aEvent, bool aDontRetargetEvents, nsEventStatus * aEventStatus) Line 6444 + 0xd bytes C++
> xul.dll!PresShell::HandleEvent(nsIFrame * aFrame, nsGUIEvent * aEvent, bool aDontRetargetEvents, nsEventStatus * aEventStatus) Line 6042 + 0x19 bytes C++
> xul.dll!nsViewManager::DispatchEvent(nsGUIEvent * aEvent, nsView * aView, nsEventStatus * aStatus) Line 741 C++
> xul.dll!nsView::HandleEvent(nsGUIEvent * aEvent, bool aUseAttachedEvents) Line 1084 C++
> xul.dll!nsWindow::DispatchEvent(nsGUIEvent * event, nsEventStatus & aStatus) Line 3611 + 0x10 bytes C++
> xul.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * event) Line 3635 C++
> xul.dll!mozilla::widget::NativeKey::DispatchKeyEvent(nsKeyEvent & aKeyEvent, const tagMSG * aMsgSentToPlugin) Line 800 + 0x12 bytes C++
> xul.dll!mozilla::widget::NativeKey::HandleKeyDownMessage(bool * aEventDispatched) Line 829 C++
> xul.dll!nsWindow::ProcessKeyDownMessage(const tagMSG & aMsg, bool * aEventDispatched) Line 5660 + 0x9 bytes C++
> xul.dll!nsWindow::ProcessMessage(unsigned int msg, unsigned int & wParam, long & lParam, long * aRetValue) Line 4797 C++
> xul.dll!nsWindow::WindowProcInternal(HWND__ * hWnd, unsigned int msg, unsigned int wParam, long lParam) Line 4349 + 0x17 bytes C++
> xul.dll!CallWindowProcCrashProtected(long (HWND__ *, unsigned int, unsigned int, long)* wndProc, HWND__ * hWnd, unsigned int msg, unsigned int wParam, long lParam) Line 32 + 0xf bytes C++
> xul.dll!nsWindow::WindowProc(HWND__ * hWnd, unsigned int msg, unsigned int wParam, long lParam) Line 4301 + 0x14 bytes C++
> user32.dll!771977d8()
> user32.dll!771978cb()
> user32.dll!7719787a()
> user32.dll!7719899d()
> user32.dll!771a55c6()
> user32.dll!77198a66()
> xul.dll!nsAppShell::ProcessNextNativeEvent(bool mayWait) Line 223 C++
> xul.dll!nsBaseAppShell::DoProcessNextNativeEvent(bool mayWait, unsigned int recursionDepth) Line 137 + 0x16 bytes C++
> xul.dll!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr, bool mayWait, unsigned int recursionDepth) Line 278 C++
> xul.dll!nsThread::ProcessNextEvent(bool mayWait, bool * result) Line 598 C++
> xul.dll!NS_ProcessNextEvent(nsIThread * thread, bool mayWait) Line 238 + 0xd bytes C++
> xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate) Line 81 + 0xa bytes C++
> xul.dll!MessageLoop::RunInternal() Line 220 + 0x9 bytes C++
> xul.dll!MessageLoop::RunHandler() Line 214 C++
> xul.dll!MessageLoop::Run() Line 188 C++
> xul.dll!nsBaseAppShell::Run() Line 163 C++
> xul.dll!nsAppShell::Run() Line 112 + 0x8 bytes C++
> xul.dll!nsAppStartup::Run() Line 270 C++
> xul.dll!XREMain::XRE_mainRun() Line 3871 + 0xe bytes C++
> xul.dll!XREMain::XRE_main(int argc, char * * argv, const nsXREAppData * aAppData) Line 3939 + 0x7 bytes C++
> xul.dll!XRE_main(int argc, char * * argv, const nsXREAppData * aAppData, unsigned int aFlags) Line 4152 + 0x12 bytes C++
> firefox.exe!do_main(int argc, char * * argv, nsIFile * xreDirectory) Line 275 + 0x1d bytes C++
> firefox.exe!NS_internal_main(int argc, char * * argv) Line 635 + 0xd bytes C++
> firefox.exe!wmain(int argc, wchar_t * * argv) Line 112 C++
> firefox.exe!__tmainCRTStartup() Line 552 + 0x19 bytes C
> firefox.exe!wmainCRTStartup() Line 371 C
> kernel32.dll!774f850d()
> ntdll.dll!77d7bf39()
> ntdll.dll!77d7bf0c()
Assignee | ||
Comment 14•11 years ago
|
||
nsXMLHttpRequest::Send() calls NS_ProcessNextEvent(). I'm not sure if this is correct. However, anyway, if a native event is handling, nsBaseAppShell or nsAppShell should not handle next native event.
Updated•11 years ago
|
Assignee | ||
Comment 15•11 years ago
|
||
Comment on attachment 795856 [details] [diff] [review] Patch for mozilla-central and mozilla-aurora So, let's stop storing the following char message before dispatching keydown event because during dispatching keydown event, char message may be received by bug 909665. So, IsFollowedByCharMessage() needs to check real-time information.
Attachment #795856 -
Flags: review?(jmathies)
Assignee | ||
Comment 16•11 years ago
|
||
Comment on attachment 795857 [details] [diff] [review] Patch for mozilla-beta For Beta (24), only fake char message is needed to be stored.
Attachment #795857 -
Flags: review?(jmathies)
Assignee | ||
Comment 17•11 years ago
|
||
Comment on attachment 795856 [details] [diff] [review] Patch for mozilla-central and mozilla-aurora Oops, oth of debug build is crashed.
Attachment #795856 -
Flags: review?(jmathies) → review-
Assignee | ||
Updated•11 years ago
|
Attachment #795857 -
Flags: review?(jmathies) → review-
Assignee | ||
Comment 18•11 years ago
|
||
Attachment #795856 -
Attachment is obsolete: true
Assignee | ||
Comment 19•11 years ago
|
||
Attachment #795857 -
Attachment is obsolete: true
Assignee | ||
Comment 20•11 years ago
|
||
m-c: https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=5a6981a3b49d aurora: https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=4e0fd57e2bcc beta: https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=71425c85e366 The result type of RemoveFollowingCharMessage() should be MSG rather than MSG&.
Assignee | ||
Comment 21•11 years ago
|
||
Comment on attachment 795907 [details] [diff] [review] Patch for mozilla-central and mozilla-aurora See comment 15 and comment 20 for the detail of this patch.
Attachment #795907 -
Flags: review?(jmathies)
Assignee | ||
Comment 22•11 years ago
|
||
Comment on attachment 795909 [details] [diff] [review] Patch for mozilla-beta See comment 16 and comment 20 for the detail.
Attachment #795909 -
Flags: review?(jmathies)
Updated•11 years ago
|
Attachment #795907 -
Flags: review?(jmathies) → review+
Updated•11 years ago
|
Attachment #795909 -
Flags: review?(jmathies) → review+
Assignee | ||
Comment 23•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/35eda0ced2e7
Comment 24•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/35eda0ced2e7
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
Comment 25•11 years ago
|
||
Please nominate for uplift asap so it might get into tomorrow's beta if low enough risk.
Assignee | ||
Comment 26•11 years ago
|
||
Comment on attachment 795909 [details] [diff] [review] Patch for mozilla-beta [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 855975 User impact if declined: User might meet the hang-up bug at pressing key. Testing completed (on m-c, etc.): Landed this patch on yesterday (m-c) Risk to taking this patch (and alternatives if risky): Text input from key might be broken. However, if there is regression, we can found it easily. String or IDL/UUID changes made by this patch: none NOTE: This patch changes the way to fetch native event to the old behavior.
Attachment #795909 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 27•11 years ago
|
||
Comment on attachment 795907 [details] [diff] [review] Patch for mozilla-central and mozilla-aurora [Approval Request Comment] Bug caused by (feature/regressing bug #): Bug 855975 User impact if declined: same as above, user might meet the hang-up. Testing completed (on m-c, etc.): Similar patch was landed on m-c yesterday. However, this patch isn't tested widely since beta needs different patch due to another change on 25. Risk to taking this patch (and alternatives if risky): Text input from key might be broken, but it can be found easily. Additionally, this patch cannot be tested on other branch, so, landing this ASAP is the safest way. String or IDL/UUID changes made by this patch: none.
Attachment #795907 -
Flags: approval-mozilla-beta?
Assignee | ||
Comment 28•11 years ago
|
||
Comment on attachment 795907 [details] [diff] [review] Patch for mozilla-central and mozilla-aurora Oops, I requested approval to wrong branch. See comment 26 for the detail about aurora.
Attachment #795907 -
Flags: approval-mozilla-beta? → approval-mozilla-aurora?
Assignee | ||
Comment 29•11 years ago
|
||
Comment on attachment 795909 [details] [diff] [review] Patch for mozilla-beta See comment 27 for the detail about beta. Sorry for the wrong requests!
Attachment #795909 -
Flags: approval-mozilla-aurora? → approval-mozilla-beta?
Updated•11 years ago
|
Attachment #795907 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 30•11 years ago
|
||
Comment on attachment 795909 [details] [diff] [review] Patch for mozilla-beta Approving this patch as this is a Firefox 24 regression and leads user in a hang state.It is hard to determine or get reports when Firefox hangs so there may be many users who may be getting to this state and may not have a clue what's happening. Given this needs more testing, please make sure to let QA know of any testcases that they can manually test to verify the bug and help identify any possible fallouts
Attachment #795909 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 31•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/47e89ff8715c https://hg.mozilla.org/releases/mozilla-beta/rev/78dc1995664a
Comment 32•11 years ago
|
||
(In reply to bhavana bajaj [:bajaj] from comment #30) > Comment on attachment 795909 [details] [diff] [review] > Patch for mozilla-beta > > Approving this patch as this is a Firefox 24 regression and leads user in a > hang state.It is hard to determine or get reports when Firefox hangs so > there may be many users who may be getting to this state and may not have a > clue what's happening. > > Given this needs more testing, please make sure to let QA know of any > testcases that they can manually test to verify the bug and help identify > any possible fallouts Needinfo'ing :masayuki and Jimm to help with some input on testing scenario's for QA
Flags: needinfo?(masayuki)
Flags: needinfo?(jmathies)
Assignee | ||
Comment 33•11 years ago
|
||
(In reply to bhavana bajaj [:bajaj] from comment #32) > (In reply to bhavana bajaj [:bajaj] from comment #30) > > Comment on attachment 795909 [details] [diff] [review] > > Patch for mozilla-beta > > > > Approving this patch as this is a Firefox 24 regression and leads user in a > > hang state.It is hard to determine or get reports when Firefox hangs so > > there may be many users who may be getting to this state and may not have a > > clue what's happening. > > > > Given this needs more testing, please make sure to let QA know of any > > testcases that they can manually test to verify the bug and help identify > > any possible fallouts > > Needinfo'ing :masayuki and Jimm to help with some input on testing > scenario's for QA For checking the fix of the hang up, use the testcase (attachment 795774 [details]). Set focus to the <input> element, then, type a printable key like "a". Then, after a couple of seconds, the character is inputted without hanging up. For checking regression by the patch, type characters in normal <input> and/or <textarea>. The changed pass in the patch is performed only at character is inputted normally without neither control nor alt modifier (including AltGr). So, if there were regression by this change, you can see something wrong when you type character.
Flags: needinfo?(masayuki)
Flags: needinfo?(jmathies)
Comment 34•11 years ago
|
||
For all the below testing I used the testcase attached to this bug and the guidelines in comment 33. With the security.mixed_content.block_active_content true (default profile), I couldn't reproduce this issue on Firefox24b1. Since the bug is on Widget:Win32, I tried Windows 7 32bit and 64bit, Windows XP 32bit and Windows Vista 32bit, but I didn't get one hang on any of them. With the security.mixed_content.block_active_content false, I get the hang every time. Verified on: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (20130829135643) No hangs regardless of the mixed content preference value. The typing does work slowly with it false though (I type a char, then I have to wait 1-2 seconds until its displayed, but there's no hang). I also did some exploratory testing around textareas and input fields both with the mixed content pref true and false. I used some of the most popular sites, like facebook, google, twitter, yahoo etc and everything went well.
Comment 35•11 years ago
|
||
Alexey, if you could reproduce this issue with security.mixed_content.block_active_content true (default value), please try to verify this fix on Firefox 24 beta 7.
Flags: needinfo?(tigeral)
Comment 36•11 years ago
|
||
I was able to verify this is fixed on 24 beta 7 with security.mixed_content.block_active_content true
Flags: needinfo?(tigeral)
Comment 37•11 years ago
|
||
I used the testcase from Comment 0 to test this issue on FF 25b4 on Windows 7 x64, Ubuntu 13.04 x86 and Mac OS 10.8.4. I was not able to find any hang, but on Windows 7 x64 there is a short delay between typing in the text box and the appearance of text (about 2 sec). On Mac and Ubuntu the text appears instantly. I got same results for both security.mixed_content.block_active_content - false or true.
Comment 38•11 years ago
|
||
I have encountered one hang on Windows 7 x64 using Nightly 24, BuildID: 20130624031040 but not as bad as mentioned in Comment 0. The hang disappeared after about 2 secs and FF worked as expected after that.
Comment 39•11 years ago
|
||
I confirm the fix is verified on Latest Aurora 26 (20131014004003) too.
Updated•10 years ago
|
QA Contact: twalker
You need to log in
before you can comment on or make changes to this bug.
Description
•