browser_tabview_*_perwindowpb.js

RESOLVED FIXED in Firefox 32

Status

()

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: jmaher, Assigned: ttaubert)

Tracking

unspecified
Firefox 34
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox32 fixed, firefox33 fixed, firefox34 fixed, firefox-esr31 fixed)

Details

Attachments

(1 attachment)

we have 3 tests which are seem to cause a crash in mochitest browser-chrome while running just the directory (not a full set of directories and subdirectories).  This is the "components/tabview/test/" directory.

Look at the bc1 column for all platforms for these 3 try runs where we have uncommented a single test at a time to show the error:

browser_tabview_bug624727_perwindowpb.js:
https://tbpl.mozilla.org/?tree=Try&rev=e77cc4c2768b

browser_tabview_bug650280_perwindowpb.js:
https://tbpl.mozilla.org/?tree=Try&rev=5266cd7a73cd

browser_tabview_privatebrowsing_perwindowpb.js:
https://tbpl.mozilla.org/?tree=Try&rev=b261c33d240a

These all seem to be the same error:
https://tbpl.mozilla.org/php/getParsedLog.php?id=44177751&tree=Try

We are planning on switching the browser-chrome tests to run per directory which would mean these would fail and either need to be fixed or disabled until we can fix them.
Gavin, can you help find an owner and prioritize this?
Flags: needinfo?(gavin.sharp)
That's pretty much the same as bug 1027084. Not using about:home would help.
I don't see us using about:home directly so it's probably loaded when opening new windows.
is there a way to use about:blank or something else?
Yup :)
Assignee: nobody → ttaubert
Status: NEW → ASSIGNED
Flags: needinfo?(gavin.sharp)
Tests run locally, they did crash before. Joel, can you please give this a try run with your patches on top?
Attachment #8459621 - Flags: review?(smacleod)
Comment on attachment 8459621 [details] [diff] [review]
0001-Bug-1041527-Ensure-that-about-home-isn-t-the-initial.patch

Stealing the review.
Attachment #8459621 - Flags: review?(smacleod) → review+
oh, let me add this to my queue and see what happens :)
Pushed to try:
https://tbpl.mozilla.org/?tree=Try&rev=9a2b271154eb

I will retrigger this afternoon and see the results tonight or tomorrow morning.
given the fact that we had perma orange prior to this patch and now bc1 has full green for 3 of each build, I think this does the trick!

https://tbpl.mozilla.org/?tree=Try&rev=9a2b271154eb

Thanks for doing this and being fast about it.  Any chance the linux bc3 failures for privatebrowsing could benefit from this same fix?
(In reply to Joel Maher (:jmaher) from comment #10)
> Thanks for doing this and being fast about it.  Any chance the linux bc3
> failures for privatebrowsing could benefit from this same fix?

Pushed a possible fix for those to try, let's see how that works out. Couldn't reproduce those locally unfortunately...

https://tbpl.mozilla.org/?tree=Try&rev=e7d620089705
Keywords: leave-open
Oh, wait. Wouldn't I have to include the patch that enables --run-by-dir?
did that here:
https://tbpl.mozilla.org/?tree=Try&rev=ad4eeefd37f9

(fyi- I didn't update my repo to compare this change to the previous try push)
it seems as though this magic trick doesn't work for the ssl test, but we gave it a try!
Guess we should take those leaks to a different bug.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Keywords: leave-open
Resolution: --- → FIXED
Target Milestone: --- → Firefox 34
QA Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.