Closed Bug 946723 Opened 11 years ago Closed 10 years ago

Test failure "controller.waitForPageLoad(): Timeout waiting for page loaded (URI=about:blank, readyState=uninitialized)" in /testSecurity/testSafeBrowsingNotificationBar.js

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect, P3)

Product:
Mozilla QA Graveyard
Component:
Mozmill Tests
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: cosmin-malutan, Assigned: danisielm)

References

(
URL
)

Details

(Whiteboard: [mozmill-test-failure])

Attachments

(5 files, 2 obsolete files)

minimized.js
681 bytes, application/javascript
andrei
: feedback-
Details
skip_v2.patch
1.94 KB, patch
andrei
: review+
andrei
: checkin+
Details | Diff | Splinter Review
unskip.patch
1.99 KB, patch
AndreeaMatei
: review+
Details | Diff | Splinter Review
request1.txt
2.72 KB, text/plain
Details
unskip-esr24.patch
1.76 KB, patch
andrei
: review+
andrei
: checkin+
Details | Diff | Splinter Review 
This failed 5 times in row on 
mm-win-7-32-2 with Aurora it
http://mozmill-daily.blargon7.com/#/remote/report/0bbed480c5898d9d02bca5d1796f597c
mm-win-81-32-3 with Aurora it 
http://mozmill-daily.blargon7.com/#/remote/report/0bbed480c5898d9d02bca5d1796f5743
mm-win-8-32-2 with Aurora it
http://mozmill-daily.blargon7.com/#/remote/report/0bbed480c5898d9d02bca5d1796f4ca5

When trying to reproduce doesn't fail with waitForPageload but with wait for element:
"Timeout exceeded for waitForElement ID: ignoreWarningButton"
Attached patch skip.patch (obsolete) — — Splinter Review 
I can reproduce a failure with this test constantly locally. What we see is  'Timeout exceeded for waitForElement ID: ignoreWarningButton' instead of a waitForPageLoad and it's visible that the warning page is never shown in the first place.

Until we can come with a fix I made a skip patch to prevent future failures.
Assignee: nobody → mario.garbi
Attachment #8343070 - Flags: review?(hskupin)
Attachment #8343070 - Flags: review?(dave.hunt)
Attachment #8343070 - Flags: review?(andrei.eftimie)
Attachment #8343070 - Flags: review?(andreea.matei)
Attached file minimized.js — 
I have attached a minimized testcase that shows what happens on Win 6.2 machines. Apparently the first URL ignores the warning page and the second will show the notification page correctly if we would be to simply load them with no checks. I have tested this by changing the order and it's not page related (either one first will get loaded, ignoring the notification page).

The minimized test loads a phishing test page and checks for the ignoreWarningButton that should be present on the notification page. It's visible that the security notification page is never loaded.

I will look further into why this is happening. I have tried opening a Firefox client using mozmill -b and the notification pages seem to work just fine... this happens just when we run a test with mozmill -t or an automated script.
Attachment #8343088 - Flags: feedback?
This failed on Mac osx 10.6.8 with Release en-US:
http://mozmill-release.blargon7.com/#/remote/report/0bbed480c5898d9d02bca5d179815a13
OS: Windows 7 → All
Comment on attachment 8343088 [details]
minimized.js

Please remove any external dependencies from minimized testcases.
Attachment #8343088 - Flags: feedback? → feedback-
Comment on attachment 8343070 [details] [diff] [review]
skip.patch

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

Since this appears to start failing on other platforms as well (see comment 3),
please update the patch to include all platforms.
Attachment #8343070 - Flags: review?(hskupin)
Attachment #8343070 - Flags: review?(dave.hunt)
Attachment #8343070 - Flags: review?(andrei.eftimie)
Attachment #8343070 - Flags: review?(andreea.matei)
Attachment #8343070 - Flags: review-
Attached patch skip_v2.patch (obsolete) — — Splinter Review 
Updated the patch to disable it on all platforms.
Attachment #8343070 - Attachment is obsolete: true
Attachment #8343582 - Flags: review?(andrei.eftimie)
Attached patch skip_v2.patch — — Splinter Review 
Fixed a minor typo
Attachment #8343582 - Attachment is obsolete: true
Attachment #8343582 - Flags: review?(andrei.eftimie)
Attachment #8343584 - Flags: review?(andrei.eftimie)
I've disabled this across branches.

Since you are able to reproduce the failure constantly (at least on some branches/platforms).
I've also bumped this as P1.

Let's get to to bottom of this failure.
Status: NEW → ASSIGNED
status-firefox25: --- → wontfix
status-firefox26: --- → disabled
status-firefox27: affected → disabled
status-firefox28: --- → disabled
status-firefox-esr17: --- → wontfix
status-firefox-esr24: --- → disabled
Priority: P2 → P1
That's what I was hoping. Great. Lets get it unskipped then!
Attached patch unskip.patch — — Splinter Review 
Unskip patch for Nightly as requested
Attachment #8357130 - Flags: review?(hskupin)
Attachment #8357130 - Flags: review?(andrei.eftimie)
Attachment #8357130 - Flags: review?(andreea.matei)
Comment on attachment 8357130 [details] [diff] [review]
unskip.patch

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

http://hg.mozilla.org/qa/mozmill-tests/rev/ffb5df3af006 (default)

Please make sure it's safe to unskip the other branches too.
Attachment #8357130 - Flags: review?(hskupin)
Attachment #8357130 - Flags: review?(andrei.eftimie)
Attachment #8357130 - Flags: review?(andreea.matei)
Attachment #8357130 - Flags: review+
status-firefox29: --- → fixed
Whiteboard: [mozmill-test-failure][mozmill-test-skipped]
So what's up here? How often does it still fail?
There was only one failure, which Andreea mentioned in comment 14, so far. I am trying to reproduce the failure on WinXP and Win 8 local machines and I will come with a fix as soon as I figure out what happens (it doesn't seem to be the same issue as we had with 1.5.24).
Considering the low frequency of this bug it's safe to lower the priority to a P3.
Priority: P1 → P3
I tried to reproduce it locally on a windows machines (Win8 and WinXP) and only managed to reproduce it once on Default. I have tried both by running testrun scripts and single test runs using mozmill -t.
I will continue trying to identify the cause of this failure.

http://mozmill-crowd.blargon7.com/#/remote/reports?branch=All&platform=Win&from=2014-01-13&to=2014-01-15
(In reply to mario garbi from comment #18)
> I will continue trying to identify the cause of this failure.

This is a P3 bug. You should better make use of your time by switching to a P1 or P2.
Actually failed multiple times:
http://mozmill-daily.blargon7.com/#/remote/report/94e33fe3d7ec0be6dbbfa0a70255a5e2
http://mozmill-daily.blargon7.com/#/remote/report/94e33fe3d7ec0be6dbbfa0a702559a61

(we need Top Failures on Remote Testruns so we can properly track these issues)
Which waitForPageLoad() call is that exactly? Nowadays this should only happen when we do not correctly trigger the event which causes a page to be loaded.
Depends on: 980938
No longer depends on: 980938
Failed 3 times with Beta 29.0b4 en-US, at waiting for about:blank it appears, this is the line affected:
http://hg.mozilla.org/qa/mozmill-tests/file/mozilla-beta/firefox/tests/remote/testSecurity/testSafeBrowsingNotificationBar.js#l119

This is not disabled on beta anymore, I guess do to the merge.

http://mozmill-release.blargon7.com/#/remote/failure?app=All&branch=All&platform=All&from=2014-03-31&to=&test=%2FtestSecurity%2FtestSafeBrowsingNotificationBar.js&func=testNotificationBar
Summary: Test failure "controller.waitForPageLoad(): Timeout waiting for page loaded" in /testSecurity/testSafeBrowsingNotificationBar.js → Test failure "controller.waitForPageLoad(): Timeout waiting for page loaded (URI=about:blank, readyState=uninitialized)" in /testSecurity/testSafeBrowsingNotificationBar.js
This failed on Nightly en-US too across different platforms:
http://mozmill-daily.blargon7.com/#/remote/report/eeab4d15c588c5e6f00ab97aa53b0509
This fails when we open a page in a new tab by clicking on the 'notAForgeryButton' element.
Sometimes it may not gather the new page we have to wait for, but the old about:blank page and fails waiting for it.
Assignee: mario.garbi → daniel.gherasim
This failed a lot over the weekend:
http://mozmill-daily.blargon7.com/#/remote/failure?app=All&branch=All&platform=All&from=2014-04-07&to=&test=%2FtestSecurity%2FtestSafeBrowsingNotificationBar.js&func=testNotificationBar

Most of the failures are readyState=loading, so I guess for a starter here we should increase the timeout for waiting for page to load.
(In reply to Cosmin Malutan from comment #28)
> This failed a lot over the weekend:
> http://mozmill-daily.blargon7.com/#/remote/
> failure?app=All&branch=All&platform=All&from=2014-04-
> 07&to=&test=%2FtestSecurity%2FtestSafeBrowsingNotificationBar.
> js&func=testNotificationBar
> 
> Most of the failures are readyState=loading, so I guess for a starter here
> we should increase the timeout for waiting for page to load.

The default timeout value from waitForPageLoad is 30s.
I feel it _should_ be enough, but as we can't control network availability, maybe increasing it will help reduce these failures. Should we aim for... 60s? This might increase our testruns a bit, but that's only when we would get a failure. Is this will reduce failure rate its only a win.

Henrik do you think this might help us?
And if yes, should we:
1) try increasing the default timeout value in mozmill?
2) or take every instance where waitForPageLoad() fails on a more regular basis and increase the timeout selectively in mozmill-tests?
Flags: needinfo?(hskupin)
I don't think this will help us a lot. If there is a network issue, we still wouldn't be able to load those remote pages. What does this remote page actually load? Are there any external references for other js files or such in that html?
Flags: needinfo?(hskupin)
Attached file request1.txt — 
(In reply to Henrik Skupin (:whimboo) from comment #30)
> I don't think this will help us a lot. If there is a network issue, we still
> wouldn't be able to load those remote pages. What does this remote page
> actually load? Are there any external references for other js files or such
> in that html?

Here's what is being loaded in this particular case.

Besides the main document, we have additional resources from the main domain (CSS, JS, Images) plus:
- JS from: jserror.newrelic.com and beacon-2.newrelic.co
- fonts from: fonts.googleapis.com and themes.googleusercontent.com
- JS from: ajax.cloudflare.com
- GA from: ssl.google-analytics.com

Since we switched the heuristics for waitForPageLoad() to fire on DOM Ready instead on Content Loaded external dependencies should not affect us. Maybe we still have some issues in waitForPageLoad?

In theory waitForPageLoad should trigger once the initial request has been downloaded and parsed... if this functions correctly could it be that our requests are not getting correctly handled, or that we are being throttled...
No, we are waiting for 'complete' and not 'interactive'. But even if we would switch the state, here we are stuck in 'loading'. Might be that any of the above additional resources were slowly or not responding.

Do we have a timeframe when this totally failed? Maybe we can ask IT if they discovered something strange with proxies.
It's been a month & 9 days since the last fail here.
I also see that the stopBadware page has been changed now (as I remember it looked differently) :

https://www.stopbadware.org/firefox?hl=ru&url=https%3A%2F%2Fwww.itisatrap.org%2Ffirefox%2Fits-an-attack.html

The page loading may be improved now and hope we won't interfere with this again.
Marked the bug as WFM for now.
URL: http://mozmill-daily.blargon7.com/#/r... → http://mozmill-daily.blargon7.com/#/r...
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Ops, looks like this is disabled on ESR24 due to this bug. 
I will unskip it, run some tests & provide the unskip patch here if all runs fine.
Status: RESOLVED → REOPENED
status-firefox25: wontfix → ---
status-firefox26: disabled → ---
status-firefox27: disabled → ---
status-firefox28: disabled → ---
status-firefox29: affected → ---
status-firefox-esr17: wontfix → ---
Resolution: WORKSFORME → ---

        Attachment #8453063 -
        Flags: review?(andrei.eftimie)

    
    

    
  
Comment on attachment 8453063 [details] [diff] [review]
unskip-esr24.patch

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

Unskipped:
https://hg.mozilla.org/qa/mozmill-tests/rev/9f98d3bc8b11 (mozilla-esr24)

        Attachment #8453063 -
        Flags: review?(andrei.eftimie)

        Attachment #8453063 -
        Flags: review+

        Attachment #8453063 -
        Flags: checkin+

    
    

    
  
Thanks Daniel for the check here.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago

          status-firefox-esr24:
          disabled → ---
Resolution: --- → WORKSFORME
Whiteboard: [mozmill-test-failure][mozmill-test-skipped] → [mozmill-test-failure]

    
  
Product: Mozilla QA → Mozilla QA Graveyard

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: