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)

Product:
Core
Component:
Widget: Win32
Version:
24 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla26
Tracking Flags:
Tracking Status
firefox23 --- unaffected
firefox24 + verified
firefox25 + verified
firefox26 + verified

People

(Reporter: tigeral, Assigned: masayuki)

References

(Depends on 1 open bug)

Details

(Keywords: hang, regression, testcase)

Attachments

(3 files, 2 obsolete files)

testcase
331 bytes, text/html
Details
Patch for mozilla-central and mozilla-aurora
7.30 KB, patch
jimm
: review+
bajaj
: approval-mozilla-aurora+
Details | Diff | Splinter Review
Patch for mozilla-beta
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
See Also: → 907278
Whiteboard: Firefox24 onkeydown synchronous XMLHttpRequest
Component: Untriaged → XML
Product: Firefox → Core
Not sure where this should go, so leaving it on General.
Component: XML → General
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
(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.
Flags: needinfo?(bugs)
Flags: needinfo?(bugs)
Keywords: regressionwindow-wanted
Keywords: qawanted
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hmm, it's very odd. The bug tried to just move the old code to new place... I'll investigate this ASAP.
Keywords: hang
Attached file testcase — 

    
    

    
  
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.

    
    

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

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch for mozilla-central and mozilla-aurora (obsolete)
        — 
          — Splinter Review
      

    


  
Assignee: nobody → masayuki
Status: NEW → ASSIGNED

    
    

    
  
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.
Component: DOM → Widget: Win32

    
    

    
  
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()

    
    

    
  
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.

    
  
Keywords: qawanted → testcase

    
    

    
  
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)

    
    

    
  
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)

    
    

    
  
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-

        Attachment #795857 -
        Flags: review?(jmathies) → review-

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch for mozilla-beta
        — 
          — Splinter Review
      

    


  

        Attachment #795857 -
        Attachment is obsolete: true

    
    

    
  
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)

    
    

    
  
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)

    
  

        Attachment #795907 -
        Flags: review?(jmathies) → review+

    
  

        Attachment #795909 -
        Flags: review?(jmathies) → review+

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/35eda0ced2e7
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26

    
    

    
  
Please nominate for uplift asap so it might get into tomorrow's beta if low enough risk.

          status-firefox26:
          affected → fixed

          tracking-firefox24:
          ? → +

          tracking-firefox25:
          ? → +

          tracking-firefox26:
          ? → +

    
    

    
  
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?

    
    

    
  
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?

    
    

    
  
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?

    
    

    
  
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?

        Attachment #795907 -
        Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

    
    

    
  
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+
Keywords: verifyme
QA Contact: twalker

    
    

    
  
(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)

    
    

    
  
(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)

    
    

    
  
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.

          status-firefox24:
          fixed → verified

    
    

    
  
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)

    
    

    
  
I was able to verify this is fixed on 24 beta 7 with security.mixed_content.block_active_content true
Flags: needinfo?(tigeral)

    
    

    
  
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.

          status-firefox25:
          fixed → verified

    
    

    
  
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.

    
    

    
  
I confirm the fix is verified on Latest Aurora 26 (20131014004003) too.
Status: RESOLVED → VERIFIED

          status-firefox26:
          fixed → verified
Keywords: verifyme
QA Contact: twalker

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: