Closed Bug 983490 Opened 10 years ago Closed 10 years ago

Intermittent test_browserElement_oop_SetInputMethodActive.html,test_browserElement_inproc_SetInputMethodActive.html | Failed to deactivate the second iframe in time.

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Version:
29 Branch
Platform:
All
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla32
Tracking Flags:
Tracking Status
firefox30 --- disabled
firefox31 --- disabled
firefox32 --- fixed
firefox-esr24 --- unaffected
b2g-v1.2 --- unaffected
b2g-v1.3 --- disabled
b2g-v1.4 --- disabled
b2g-v2.0 --- fixed

People

(Reporter: KWierso, Assigned: timdream)

References

Details

(Keywords: intermittent-failure, Whiteboard: [FT:System-Platform][rr])

Attachments

(1 file, 3 obsolete files)

Patch for commit (Try 2 - with typo in comment fixed)
10.05 KB, patch
timdream
: review+
Details | Diff | Splinter Review 
https://tbpl.mozilla.org/php/getParsedLog.php?id=36098592&tree=Mozilla-Inbound
slave: tst-linux64-spot-450




15:41:59     INFO -  603 INFO TEST-START | /tests/dom/browser-element/mochitest/test_browserElement_oop_SetInputMethodActive.html
15:42:01     INFO -  ############################### browserElementPanning.js loaded
15:42:01     INFO -  ######################## BrowserElementChildPreload.js loaded
15:42:01     INFO -  ############################### browserElementPanning.js loaded
15:42:02     INFO -  ######################## BrowserElementChildPreload.js loaded
15:42:02     INFO -  ############################### browserElementPanning.js loaded
15:42:02     INFO -  ######################## BrowserElementChildPreload.js loaded
15:42:05     INFO -  inputcontext is received for input method #0
15:42:05     INFO -  sending text in input method #0
15:42:06     INFO -  inputcontext is removed for input method #0
15:42:06     INFO -  inputcontext is received for input method #1
15:42:06     INFO -  sending text in input method #1
15:42:07     INFO -  sending text in input method #1
15:42:07     INFO -  sending text in input method #1
15:42:07     INFO -  inputcontext is removed for input method #1
15:42:07     INFO -  604 INFO TEST-INFO | dumping last 9 message(s)
15:42:07     INFO -  605 INFO TEST-INFO | if you need more context, please use SimpleTest.requestCompleteLog() in your test
15:42:07     INFO -  606 INFO TEST-PASS | /tests/dom/browser-element/mochitest/test_browserElement_oop_SetInputMethodActive.html | Can access setInputMethodActive.
15:42:07     INFO -  607 INFO TEST-PASS | /tests/dom/browser-element/mochitest/test_browserElement_oop_SetInputMethodActive.html | Can access setInputMethodActive.
15:42:07     INFO -  608 INFO TEST-PASS | /tests/dom/browser-element/mochitest/test_browserElement_oop_SetInputMethodActive.html | Can access setInputMethodActive.
15:42:08     INFO -  609 INFO TEST-PASS | /tests/dom/browser-element/mochitest/test_browserElement_oop_SetInputMethodActive.html | setInputMethodActive succeeded (0).
15:42:08     INFO -  610 INFO TEST-PASS | /tests/dom/browser-element/mochitest/test_browserElement_oop_SetInputMethodActive.html | Failed to get correct input from the first iframe.
15:42:08     INFO -  611 INFO TEST-PASS | /tests/dom/browser-element/mochitest/test_browserElement_oop_SetInputMethodActive.html | setInputMethodActive succeeded (1).
15:42:08     INFO -  612 INFO TEST-PASS | /tests/dom/browser-element/mochitest/test_browserElement_oop_SetInputMethodActive.html | Failed to get correct input from the second iframe.
15:42:08     INFO -  613 INFO TEST-PASS | /tests/dom/browser-element/mochitest/test_browserElement_oop_SetInputMethodActive.html | Failed to get correct input from the second iframe.
15:42:08     INFO -  614 INFO TEST-PASS | /tests/dom/browser-element/mochitest/test_browserElement_oop_SetInputMethodActive.html | setInputMethodActive(false) succeeded (3).
15:42:08     INFO -  615 INFO TEST-UNEXPECTED-FAIL | /tests/dom/browser-element/mochitest/test_browserElement_oop_SetInputMethodActive.html | Failed to deactivate the second iframe in time.
15:42:08     INFO -  616 INFO TEST-INFO | MEMORY STAT vsize after test: 97796096
15:42:08     INFO -  617 INFO TEST-INFO | MEMORY STAT residentFast after test: 52682752
15:42:08     INFO -  618 INFO TEST-INFO | MEMORY STAT heapAllocated after test: 18462824
15:42:08     INFO -  619 INFO TEST-END | /tests/dom/browser-element/mochitest/test_browserElement_oop_SetInputMethodActive.html | finished in 9040ms
15:42:09     INFO -  620 INFO TEST-START | /tests/dom/browser-element/mochitest/test_browserElement_oop_SetVisible.html
https://tbpl.mozilla.org/php/getParsedLog.php?id=37295636&tree=Fx-Team
Summary: Intermittent test_browserElement_oop_SetInputMethodActive.html | Failed to deactivate the second iframe in time. → Intermittent test_browserElement_oop_SetInputMethodActive.html,test_browserElement_inproc_SetInputMethodActive.html | Failed to deactivate the second iframe in time.
I have this in an rr recording.
Whiteboard: [rr]
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) (PTO April 25 to May 3) from comment #27)
> I have this in an rr recording.

This intermittent failure is #12 on OrangeFactor, and as such worthy of escalation due to https://wiki.mozilla.org/Sheriffing/Test_Disabling_Policy

Needinfo'ing an appropriate person for estimation of next steps & timeframe. The policy requires that I state that after two working days a needinfo on the module owner will be added (if they aren't already), and failing that - the test disabled (or suite hidden if disabling isn't an option) 2 working days after that. But that's an absolutely last resort :-)

Yuan - could you work with Rob to see if the RR recording can shed any light on this? :-)
Flags: needinfo?(xyuan)
(In reply to Ed Morley [:edmorley UTC+0] from comment #101)
> Needinfo'ing an appropriate person for estimation of next steps & timeframe.
> The policy requires that I state that after two working days a needinfo on
> the module owner will be added (if they aren't already), and failing that -
> the test disabled (or suite hidden if disabling isn't an option) 2 working
> days after that. But that's an absolutely last resort :-)

Johnny, I think we're at module owner needinfo time here. This and bug 987928 remain two of our top oranges with no activity. Can you please help us find an owner to get this resolved before we need to resort to disabling the tests?
Flags: needinfo?(jst)
Disabled per comment 151.
https://hg.mozilla.org/integration/mozilla-inbound/rev/4cafec48a1f0
Flags: needinfo?(xyuan)
Flags: needinfo?(jst)
Whiteboard: [rr] → [rr][test disabled][leave open]
Assignee: nobody → timdream
Blocks: 974770
Status: NEW → ASSIGNED
Attached patch WIP (obsolete) — — Splinter Review 
This patch re-enabled the test done in bug 981997 and remove all setInterval() and setTimeout(), hopefully this could make test run faster and get rid of all intermittents (this bug, bug 597213, bug 987928)

I enabled this test on Android too to see if we fix this there too.
Attachment #8426061 - Flags: review?(xyuan)
It looks like we still need to disable the test on Android.
Comment on attachment 8426061 [details] [diff] [review]
WIP

Review of attachment 8426061 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/browser-element/mochitest/browserElement_SetInputMethodActive.js
@@ +147,5 @@
> +
> +  if (wrappedMsg.data.error) {
> +    ok(false, wrappedMsg.data.value);
> +
> +    return;

Should we increase gCount before return?
Attachment #8426061 - Flags: review?(xyuan) → review+
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #199)
> It looks like we still need to disable the test on Android.

We already disabled the input method API on android, so it's OK to disable this related one as well.
(In reply to Yuan Xulei [:yxl] from comment #200)
> Should we increase gCount before return?

Doesn't matter, the test would be failed at that point.
Attached patch Patch for commit (obsolete) — — Splinter Review 

        Attachment #8426061 -
        Attachment is obsolete: true

        Attachment #8426858 -
        Flags: review+

    
    

    
  
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #205)
> Looks like this is still failing intermittently. Backed out.
> https://hg.mozilla.org/integration/mozilla-inbound/rev/684840123504
> 
> https://tbpl.mozilla.org/php/getParsedLog.php?id=40198739&tree=Mozilla-
> Inbound

I would personally prefer the patch stays in as we dig further on why the focus lost unexpectedly. But if there is a rule exist against that don't worry about it.

Xulei, Olli, would you mind looking at the log above? What can we do to find out who take the focus away? Is it possible to enter some "mode" during tests that ignores events from the OS? Thanks!
Flags: needinfo?(xyuan)
Flags: needinfo?(bugs)

    
    

    
  
:kanru told me to try focusmanager.testmode. I will push a path to try with that and run the test 100 times.
Flags: needinfo?(xyuan)
Flags: needinfo?(bugs)

    
    

    
  
From the log, the focus was taken away accidentally during the test. I don't know if we run multiple tests parallelly on the same device. If so, other test may grab the focus.

We have |SimpleTest.waitForFocus| to require window foucs (https://developer.mozilla.org/en-US/docs/Mozilla/QA/Avoiding_intermittent_oranges#Tests_which_require_focus). Is it possible to retrieve the focus and continue the test if the input field got blurred?

    
    

    
  
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #207)
> :kanru told me to try focusmanager.testmode. I will push a path to try with
> that and run the test 100 times.

I read the log wrong. I can see the ERROR even with green runs like
https://tbpl.mozilla.org/php/getParsedLog.php?id=40078603&tree=Try&full=1#error0
https://tbpl.mozilla.org/php/getParsedLog.php?id=40202699&tree=Mozilla-Inbound&full=1

The cause of that is because my detection code in the test does not turn itself off when the test is finished. I add a check to do that (simply below)

          if (input.value === '#0#1hello') {
            return;
          }

    
    

    
  
(In reply to Yuan Xulei [:yxl] from comment #208)
> From the log, the focus was taken away accidentally during the test. I don't
> know if we run multiple tests parallelly on the same device. If so, other
> test may grab the focus.
> 
> We have |SimpleTest.waitForFocus| to require window foucs
> (https://developer.mozilla.org/en-US/docs/Mozilla/QA/
> Avoiding_intermittent_oranges#Tests_which_require_focus). Is it possible to
> retrieve the focus and continue the test if the input field got blurred?

Yeah, I can do this too.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch for commit (Try 2) (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #8426858 -
        Attachment is obsolete: true

        Attachment #8427498 -
        Flags: review?(xyuan)

    
    

    
  
So I didn't set focusmanager.testmode in this patch because it does not appear to have an effort on my machine and I don't see any tests turn this on explicitly, in dxr.

    
    

    
  
Comment on attachment 8427498 [details] [diff] [review]
Patch for commit (Try 2)

Review of attachment 8427498 [details] [diff] [review]:
-----------------------------------------------------------------

I give r+, but it may not resolve the focus issue completely. The patch ensures the focus at the beginning. But we might lose it later in the middle of the test.

        Attachment #8427498 -
        Flags: review?(xyuan) → review+

    
    

    
  
Actually, I don't think here is an evidence of unexpected lost of focus in the test environment. The summary of this bug and bug 987928 is all about setInterval() commit the text more than once before the input method is disabled, which is a race that my patch get rid of.

I however need more information on bug 957213.

I will set checkin-needed once try completes, hopefully today.

    
    

    
  
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #215)
> I however need more information on bug 957213.

OK, stupid me, bug 957213 was about another test and it is not disabled. So let's dealt with it separately.
No longer blocks: 957213

    
    

    
  


  
Fix a comment typo.

        Attachment #8427498 -
        Attachment is obsolete: true

        Attachment #8427652 -
        Flags: review+

    
    

    
  
Ryan, should I close this bug since there are no more errors from TBPL?

(Tomcat ask me to needinfo you.)
Flags: needinfo?(ryanvm)

    
    

    
  
The test was re-enabled in comment 218; seems like it's working well now - thank you :-)
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: needinfo?(ryanvm)
Resolution: --- → FIXED
Whiteboard: [rr][test disabled][leave open] → [rr]

          status-firefox32:
          disabled → fixed
Target Milestone: --- → mozilla32
Whiteboard: [rr] → [FT:System-Platform][rr]
Component: DOM → DOM: Core & HTML

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: