Closed Bug 1423959 Opened 8 years ago Closed 6 years ago

Intermittent docshell/test/browser/browser_loadURI_postdata.js | post data was submitted correctly - "" == "postdata=true" -

Categories

(Core :: DOM: Navigation, defect, P2)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Project Flags:
Fission Milestone M4.1

People

(Reporter: intermittent-bug-filer, Assigned: u608768)

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell disabled])

Attachments

(3 files, 1 obsolete file)

Skipped test on linux and mac
721 bytes, patch
jmaher
: review+
Details | Diff | Splinter Review
Bug 1423959 - disable browser_loadURI.js on win10 r=jmaher
47 bytes, text/x-phabricator-request
Details | Review
Bug 1423959 - Cleanup browser_loadURI.js and re-enable it on all platforms, r=kmag
47 bytes, text/x-phabricator-request
Details | Review
https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Hit again in a central-as-beta simulation: https://treeherder.mozilla.org/logviewer.html#?job_id=167299938&repo=try
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
This bug had a major spike in the last 2 days and 105 failures the last 7 days. Failures happen on linux and osx platform on opt, debug and asan build types. Here is a recent log: https://treeherder.mozilla.org/logviewer.html#?job_id=194153964&repo=mozilla-inbound&lineNumber=8327 TEST-START | docshell/test/browser/browser_loadURI.js [task 2018-08-15T20:07:41.508Z] 20:07:41 INFO - TEST-INFO | started process screentopng [task 2018-08-15T20:07:42.001Z] 20:07:42 INFO - TEST-INFO | screentopng: exit 0 [task 2018-08-15T20:07:42.004Z] 20:07:42 INFO - TEST-UNEXPECTED-FAIL | docshell/test/browser/browser_loadURI.js | post data was submitted correctly - "" == "postdata=true" - [task 2018-08-15T20:07:42.004Z] 20:07:42 INFO - Stack trace: [task 2018-08-15T20:07:42.004Z] 20:07:42 INFO - resource://testing-common/content-task.js line 59 > eval:null:5 [task 2018-08-15T20:07:42.004Z] 20:07:42 INFO - resource://testing-common/content-task.js:null:60 [task 2018-08-15T20:07:42.006Z] 20:07:42 INFO - GECKO(6419) | MEMORY STAT | vsize 2062MB | residentFast 295MB | heapAllocated 118MB [task 2018-08-15T20:07:42.006Z] 20:07:42 INFO - TEST-OK | docshell/test/browser/browser_loadURI.js | took 173ms :overholt: Can you please take a look at this bug?
Flags: needinfo?(overholt)
Whiteboard: [stockwell needswork:owner] → [stockwell needswork:owner]
Attached patch Skipped test on linux and osx (obsolete) — — Splinter Review
Attachment #9001875 - Flags: review?(jmaher)
Comment on attachment 9001875 [details] [diff] [review] Skipped test on linux and osx Review of attachment 9001875 [details] [diff] [review]: ----------------------------------------------------------------- ::: docshell/test/browser/browser.ini @@ +97,4 @@ > redirect_to_example.sjs > [browser_loadDisallowInherit.js] > [browser_loadURI.js] > +skip-if = verify && !debug && os == 'mac' || (os == 'linux') || (os == 'osx') # Bug 1423959 this needs to be os == 'mac', not os == 'osx'. Also if there is an existing condition, please wrap it in () so we have no concern about order of operations. the statement: verify && !debug && os == 'mac' should be: (verify && !debug && os == 'mac')
Attachment #9001875 - Flags: review?(jmaher) → review-
Made the requested changes.
Attachment #9001875 - Attachment is obsolete: true
Attachment #9001956 - Flags: review?(jmaher)
Comment on attachment 9001956 [details] [diff] [review] Skipped test on linux and mac Review of attachment 9001956 [details] [diff] [review]: ----------------------------------------------------------------- looks good
Attachment #9001956 - Flags: review?(jmaher) → review+
Keywords: checkin-needed, leave-open
Whiteboard: [stockwell disable-recommended] → [stockwell disabled]
Pushed by ryanvm@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/1b24505ca96c Disable browser_loadURI.js on linux and osx. r=jmaher
Keywords: checkin-needed
Maybe Peter can take a look at this OS-specific failure?
Flags: needinfo?(overholt) → needinfo?(peterv)
Priority: -- → P2

There are 30 failures associated to this bug in the last 7 days. These are occurring on windows10-64 and windows10-64-qr opt builds.

:neha can you take a look at this?

Flags: needinfo?(nkochar)

In the last 7 days, there have been 49 failures on windows10-64 and windows10-64-qr platforms, opt build type.

An example of a recent log file:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=277854368&repo=mozilla-central&lineNumber=5155

And the relevant part of the log:
[task 2019-11-23T23:18:45.374Z] 23:18:45 INFO - TEST-START | docshell/test/browser/browser_loadURI.js
[task 2019-11-23T23:18:45.413Z] 23:18:45 INFO - GECKO(4236) | [Parent 5224, Gecko_IOThread] WARNING: file z:/build/build/src/ipc/chromium/src/base/process_util_win.cc, line 160
[task 2019-11-23T23:18:45.613Z] 23:18:45 INFO - TEST-INFO | started process screenshot
[task 2019-11-23T23:18:45.676Z] 23:18:45 INFO - TEST-INFO | screenshot: exit 0
[task 2019-11-23T23:18:45.676Z] 23:18:45 INFO - TEST-UNEXPECTED-FAIL | docshell/test/browser/browser_loadURI.js | post data was submitted correctly - "" == "postdata=true" -
[task 2019-11-23T23:18:45.676Z] 23:18:45 INFO - Stack trace:
[task 2019-11-23T23:18:45.676Z] 23:18:45 INFO - resource://testing-common/content-task.js line 110 > eval:null:5
[task 2019-11-23T23:18:45.676Z] 23:18:45 INFO - resource://testing-common/content-task.js:null:111
[task 2019-11-23T23:18:45.681Z] 23:18:45 INFO - GECKO(4236) | MEMORY STAT | vsize 2104211MB | vsizeMaxContiguous 65852413MB | residentFast 290MB | heapAllocated 114MB

Neha, as you are the triage owner of this component, could you please take a look at this?
Thank you!

Whiteboard: [stockwell disabled] → [stockwell disabled][stockwell needswork:owner]
Assignee: nobody → apavel
Whiteboard: [stockwell disabled][stockwell needswork:owner] → [stockwell disabled]
Pushed by apavel@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/672e5045606f disable browser_loadURI.js on win10 r=jmaher

Andreea, the recent ones at least are all fission tests, do you see non-fission runs also failing with this? If not, we can disable only the fission case and get it fixed via a separate bug blocking fission-mochitests meta.

Flags: needinfo?(peterv)
Flags: needinfo?(nkochar)
Flags: needinfo?(apavel)

This ensures that we wait for the desired URL in the browserLoaded call, rather
than resolving the first-loaded one.

Pushed by kmadan@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/653767ac17f7 Cleanup browser_loadURI.js and re-enable it on all platforms, r=kmag

This test was renamed in https://hg.mozilla.org/mozilla-central/rev/653767ac17f7. Do we usually just update the bug summary to reflect this or create a new bug if it starts failing again?

(In reply to Neha Kochar [:neha] from comment #76)

Andreea, the recent ones at least are all fission tests, do you see non-fission runs also failing with this? If not, we can disable only the fission case and get it fixed via a separate bug blocking fission-mochitests meta.

Hi Neha, failures in the last 30 days are all fission, should I make a new patch to disable on fission or wait to see if it still fails in the new version?

Flags: needinfo?(apavel) → needinfo?(nkochar)

(In reply to :kashav from comment #81)

This test was renamed in https://hg.mozilla.org/mozilla-central/rev/653767ac17f7. Do we usually just update the bug summary to reflect this or create a new bug if it starts failing again?

If the name changes we update the bug. If a new test is added with a similar name, we file a new bug.

I've updated the bug title since the test has been renamed.
Kashav, can you look into why this is failing again for fission? You had enabled it after the browserLoaded changes.

Fission Milestone: --- → M4.1
Flags: needinfo?(nkochar) → needinfo?(kmadan)
Summary: Intermittent docshell/test/browser/browser_loadURI.js | post data was submitted correctly - "" == "postdata=true" - → Intermittent docshell/test/browser/browser_loadURI_postdata.js | post data was submitted correctly - "" == "postdata=true" -

(In reply to Neha Kochar [:neha] from comment #84)

Kashav, can you look into why this is failing again for fission? You had enabled it after the browserLoaded changes.

The patch above re-enables it on all platforms (including for Fission). It looks like it's passing consistently now, but we can keep this open in case it starts failing again (perhaps less intermittently).

Flags: needinfo?(kmadan)

Thank you both!

Hasn't failed since Nov 28, closing this bug as Fixed.

Status: REOPENED → RESOLVED
Closed: 8 years ago → 6 years ago
Resolution: --- → FIXED
Assignee: apavel → kmadan
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: