Closed Bug 1137694 Opened 9 years ago Closed 9 years ago

Fix and re-enable browser_net_sort-03.js on Linux opt e10s

Categories

(DevTools :: Netmonitor, defect)

x86
Linux
defect
Not set
normal

Tracking

(e10s+, firefox39 fixed)

RESOLVED FIXED
Firefox 39
Tracking Status
e10s + ---
firefox39 --- fixed

People

(Reporter: RyanVM, Assigned: RyanVM)

Details

Attachments

(3 files, 1 obsolete file)

For some reason, browser_net_sort-03.js started failing ~50% of the time yesterday. Numerous attempts at backouts and retriggers have yielded no progress. Due to this causing an ongoing tree closure, we're disabling the test to get the trees reopened. This bug tracks finding the root cause and getting it re-enabled.
Attached file test log
Attached image test screenshot
No knowing the netmonitor test well, I can't investigate the root cause, also it looks like it's more related to recent e10s changes rather than devtools changes, because there hasn't been anything that seems related lately.
What I *can* do however, is change the test so it doesn't directly manipulate the content window CPOW anymore.
The timeout occurs right when trying to call a content window method directly, and the logs say that the CPOW is dead. This is weird, but going via a message to the frame script instead should help.
I will upload a patch in a second.
CCing some e10s folks as well.
tracking-e10s: --- → ?
/r/4427 - Bug 1137694 - Avoid calling content methods directly in browser_net_sort-03.js; r=past

Pull down this commit:

hg pull review -r 89f3376842da3dc6391ba434874949ead53abdb8
Attachment #8570503 - Flags: review?(past)
Comment on attachment 8570503 [details]
MozReview Request: bz://1137694/pbrosset

https://reviewboard.mozilla.org/r/4425/#review3603

::: browser/devtools/netmonitor/test/browser_net_sort-03.js
(Diff revision 1)
> -        .then(finish);
> -    });
> +        .then(finish, Cu.reportError);
> +    }, Cu.reportError);

Is calling Cu.reportError in browser mochitests a thing now? I'm more used to see ok(false, ...) in these cases, but if it works, that's fine.
Attachment #8570503 - Flags: review?(past)
Corrected the patch as per Panos' comments, and re-enabled the test.
Carried over the R+.
Pushed to try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6c30df15f7d5
Of course I didn't run the test locally before pushing to try and just realized that another test was using the same test HTML page I modified and now therefore fails.
I'll get this other test fixed now.
The good news is that so far, I'm not seeing browser_net_sort-03.js failing on linux opt e10s.
(In reply to Patrick Brosset [:pbrosset] [:patrick] from comment #12)
> Of course I didn't run the test locally before pushing to try and just
> realized that another test was using the same test HTML page I modified and
> now therefore fails.
> I'll get this other test fixed now.
> The good news is that so far, I'm not seeing browser_net_sort-03.js failing
> on linux opt e10s.

I don't see an updated rev on MozReview?
Keywords: checkin-needed
I might be missing something about MozReview ... I did push to review and can see the right diff on the MozReview website.
Anyway, pushed to fx-team: https://hg.mozilla.org/integration/fx-team/rev/37409aced15c
https://hg.mozilla.org/mozilla-central/rev/37409aced15c
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 39
Attachment #8570503 - Attachment is obsolete: true
Attachment #8619617 - Flags: review+
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: