Closed Bug 948801 Opened 11 years ago Closed 10 years ago

Move browser tests from toolkit/mozapps/extensions/test/browser/Makefile.in to browser.ini

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla30

People

(Reporter: markh, Assigned: ted)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 2 obsolete files)

toolkit/mozapps/extensions/test/browser has browser-chrome tests specified in Makefile.in - they should be specified in a new browser.ini
Summary: Move browser tests from dom/indexedDB/test/Makefile.in to browser.ini → Move browser tests from toolkit/mozapps/extensions/test/browser/Makefile.in to browser.ini
Assignee: nobody → mhammond
Status: NEW → ASSIGNED
Attachment #8345696 - Flags: review?(ted)
Comment on attachment 8345696 [details] [diff] [review]
Bug-948801-move-browser-chrome-tests-in-toolkit-moza.patch

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

You're breaking the MOCHITEST_BROWSER_MAIN installation rules.
Attachment #8345696 - Flags: review?(ted) → review-
He's right. I have no idea what this Makefile is doing, this stuff came from Mossop in bug 597178. Mossop: what the hell is this doing?
Flags: needinfo?(dtownsend+bugmail)
FWIW, mxr tells me that MOCHITEST_BROWSER_MAIN appears only in this Makefile.  A try run with this patch works fine - so I suspect there aren't actually any MOCHITEST_BROWSER_MAIN installation rules being broken.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #3)
> He's right. I have no idea what this Makefile is doing, this stuff came from
> Mossop in bug 597178. Mossop: what the hell is this doing?

What should be happening is the tests in MOCHITEST_BROWSER_MAIN_FILES should be getting installed to two different places so they are run twice during the browser chrome run. One set tests the case where the add-ons manager appears in a tab in the browser, the other set tests the case where the add-ons manager runs as a standalone window. Looking at a recent build it looks like that is still happening but the machanism that does it changed in bug 917622 so ping glandium if you have questions about that.
Flags: needinfo?(dtownsend+bugmail)
Depends on: 977275
Hey, I bet jmaher wants to review more Mochitest manifest patches!

On the plus side, this looks to be the last set of browser-chrome tests that were not in a manifest, so yay!

This relies on the patch from bug 948801 to make the "install-to-subdir" key in the manifest work. This is horrible, and I hope to remove this once we're running tests from manifests.
Attachment #8382468 - Flags: review?(jmaher)
Assignee: mhammond → ted
Comment on attachment 8382468 [details] [diff] [review]
move browser-chrome tests in toolkit/mozapps/extensions/test/browser from Makefile.in to browser.ini

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

::: toolkit/mozapps/extensions/test/browser/browser-window.ini
@@ +1,2 @@
> +[DEFAULT]
> +install-to-subdir = test-window

I think it is technically called browser-window, not test-window- this needs a try server run for sure :)
Attachment #8382468 - Flags: review?(jmaher) → review+
(In reply to Joel Maher (:jmaher) from comment #8)
> I think it is technically called browser-window, not test-window- this needs
> a try server run for sure :)

You are correct, this is going to wind up in a different directory, it'll be $objdir/_tests/testing/mochitest/browser/toolkit/mozapps/extensions/test/browser/test-window vs. the original $objdir/_tests/testing/mochitest/browser/toolkit/mozapps/extensions/test/browser-window .

However, the relevant bit of the tests should be fine since it just looks for "-window" in the last directory in the URL:
http://hg.mozilla.org/mozilla-central/annotate/aa54ebb903ee/toolkit/mozapps/extensions/test/browser/head.js#l16
Blocks: 977541
Unfortunately these are orange on Try, need to figure that out:
https://tbpl.mozilla.org/?tree=Try&rev=ba2a7fc59025
I figured it out. That head.js also tries to normalize the path to support files by popping the last directory off of the URL and replacing it with /browser/, which doesn't work since I moved the tests to a subdirectory. I tweaked it to generate the right path and it looks pretty good on Try so far (still waiting for debug results):
https://tbpl.mozilla.org/?tree=Try&rev=a05ce1dc692c
Attachment #8382468 - Attachment is obsolete: true
Attachment #8345696 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/eea5db7d83d8
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: