Closed
Bug 1166560
Opened 10 years ago
Closed 9 years ago
Create a head.js file for that can be shared for browser/devtools tests
Categories
(DevTools :: Framework, defect)
Tracking
(firefox41 fixed)
RESOLVED
FIXED
Firefox 41
Tracking | Status | |
---|---|---|
firefox41 | --- | fixed |
People
(Reporter: bgrins, Assigned: bgrins)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
jryans
:
review+
|
Details | Diff | Splinter Review |
The idea is that we should be sharing things across all of the devtools tests (imports / cleanup functions / utilities like addTab, getFrameScript, etc).
I believe this can be done by using an existing head.js file (like devtools/framework/head.js) and then having it import a directory-head.js file from each individual directory.
Then each of the folders that wanted to share this head.js would just update their browser.ini to point to the new one and then add a directory-head.js file with any specific functions.
Assignee | ||
Comment 1•10 years ago
|
||
What do you think? This is my proposed path forward for one head.js file to rule them all - just starting with the eyedropper directory since it's easy.
Comment 2•10 years ago
|
||
Things that I'd like to see copied over in a general case is pref resetting: https://github.com/mozilla/gecko-dev/blob/53d1e1a9e5f5025135ec3722c5ee4d3bb542ccc1/browser/devtools/performance/test/head.js#L47-L64
and gets cleared up in the unregister function.
Assignee | ||
Comment 3•10 years ago
|
||
(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #2)
> Things that I'd like to see copied over in a general case is pref resetting:
> https://github.com/mozilla/gecko-dev/blob/
> 53d1e1a9e5f5025135ec3722c5ee4d3bb542ccc1/browser/devtools/performance/test/
> head.js#L47-L64
> and gets cleared up in the unregister function.
You mean some way to declare a list of prefs / values and have the main head.js file manage setting them before the test and then resetting them afterwards? Or that the shared file would maintain such a list?
Sidenote: looks like there are lots of nice utility functions in the performance head.js file that we could pull into the shared head.js
Comment on attachment 8607855 [details] [diff] [review]
test-cleanup.patch
Review of attachment 8607855 [details] [diff] [review]:
-----------------------------------------------------------------
The idea seems great!
I think I would prefer to invert it though, so that the "main" head.js for a directory is the one in the directory and it would remain named "head.js" as it is today. More specifically:
1. The framework / shared head would be renamed to "shared-head.js"
2. In eyedropper, "head.js" would import "shared-head.js" from framework
This way, directories still have a "head.js" like the rest of Gecko test dirs, and each directory's head is in control of the importing.
What do you think?
Attachment #8607855 -
Flags: review?(jryans) → feedback+
Assignee | ||
Comment 5•10 years ago
|
||
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #4)
> Comment on attachment 8607855 [details] [diff] [review]
> test-cleanup.patch
>
> Review of attachment 8607855 [details] [diff] [review]:
> -----------------------------------------------------------------
>
> The idea seems great!
>
> I think I would prefer to invert it though, so that the "main" head.js for a
> directory is the one in the directory and it would remain named "head.js" as
> it is today. More specifically:
>
> 1. The framework / shared head would be renamed to "shared-head.js"
> 2. In eyedropper, "head.js" would import "shared-head.js" from framework
>
> This way, directories still have a "head.js" like the rest of Gecko test
> dirs, and each directory's head is in control of the importing.
>
> What do you think?
Yeah, that makes more sense
Comment 6•10 years ago
|
||
+1 jryans naming scheme
Comment 7•10 years ago
|
||
I am working on bug 859058 (Net panel HAR export) and I've created new netmonitor/har subdirectory for related code. I also wanted to create netmonitor/har/test subdir for test files and reuse the head.js file from netmonitor/test dir. Is it the right approach? Is this bug going to help me?
Honza
Flags: needinfo?(bgrinstead)
Assignee | ||
Comment 8•10 years ago
|
||
(In reply to Jan Honza Odvarko [:Honza] from comment #7)
> I am working on bug 859058 (Net panel HAR export) and I've created new
> netmonitor/har subdirectory for related code. I also wanted to create
> netmonitor/har/test subdir for test files and reuse the head.js file from
> netmonitor/test dir. Is it the right approach? Is this bug going to help me?
In that case, you can simply include something like `../../head.js` in the browser.ini for the new directory and it will automatically use the netmonitor's head.js (with or without the changes from this patch).
Flags: needinfo?(bgrinstead)
Assignee | ||
Comment 9•10 years ago
|
||
(In reply to Brian Grinstead [:bgrins] from comment #8)
> (In reply to Jan Honza Odvarko [:Honza] from comment #7)
> > I am working on bug 859058 (Net panel HAR export) and I've created new
> > netmonitor/har subdirectory for related code. I also wanted to create
> > netmonitor/har/test subdir for test files and reuse the head.js file from
> > netmonitor/test dir. Is it the right approach? Is this bug going to help me?
>
> In that case, you can simply include something like `../../head.js` in the
> browser.ini for the new directory and it will automatically use the
> netmonitor's head.js (with or without the changes from this patch).
I think I may have gotten the relative path wrong there, probably something like ../../test/head.js.
Or you could create a normal head.js file and then make something like this be the first line in it:
Services.scriptloader.loadSubScript("chrome://mochitests/content/browser/browser/devtools/netmonitor/test/head.js", this);
Assignee | ||
Comment 10•10 years ago
|
||
Inverted to use normal head.js files that import framework/test/shared-head.js
Attachment #8607855 -
Attachment is obsolete: true
Attachment #8608160 -
Flags: review?(jryans)
Comment on attachment 8608160 [details] [diff] [review]
test-cleanup.patch
Review of attachment 8608160 [details] [diff] [review]:
-----------------------------------------------------------------
::: browser/devtools/eyedropper/test/head.js
@@ +1,5 @@
> /* Any copyright is dedicated to the Public Domain.
> http://creativecommons.org/publicdomain/zero/1.0/ */
>
> +// shared-head.js handles imports, constants, and utility functions
> +Services.scriptloader.loadSubScript("chrome://mochitests/content/browser/browser/devtools/framework/test/shared-head.js", this);
Does this work if you run the eyedropper directory only after clobbering?
The part I am unsure about is: eyedropper's browser.ini does not include shared-head.js as a support-file, and this path references it from the framework directory.
If it works when running only that directory, then I guess all support-files for all dirs are installed before running any tests.
Attachment #8608160 -
Flags: review?(jryans) → review+
Assignee | ||
Comment 12•10 years ago
|
||
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #11)
> Comment on attachment 8608160 [details] [diff] [review]
> test-cleanup.patch
>
> Review of attachment 8608160 [details] [diff] [review]:
> -----------------------------------------------------------------
>
> ::: browser/devtools/eyedropper/test/head.js
> @@ +1,5 @@
> > /* Any copyright is dedicated to the Public Domain.
> > http://creativecommons.org/publicdomain/zero/1.0/ */
> >
> > +// shared-head.js handles imports, constants, and utility functions
> > +Services.scriptloader.loadSubScript("chrome://mochitests/content/browser/browser/devtools/framework/test/shared-head.js", this);
>
> Does this work if you run the eyedropper directory only after clobbering?
>
> The part I am unsure about is: eyedropper's browser.ini does not include
> shared-head.js as a support-file, and this path references it from the
> framework directory.
>
> If it works when running only that directory, then I guess all support-files
> for all dirs are installed before running any tests.
Just tested this and it does indeed work (just like the import of commandline/test/helpers.js). It seems install-tests includes all dirs.
Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=281b89f3893e
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Assignee | ||
Comment 13•10 years ago
|
||
Keywords: checkin-needed
Whiteboard: [fixed-in-fx-team]
Comment 14•9 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox41:
--- → fixed
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 41
Assignee | ||
Updated•9 years ago
|
Blocks: shared-head
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•