Move Browser* helper functions used from global menubar and similar commands to a single object in a separate file, loaded as-needed
Categories
(Firefox :: General, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox127 | --- | fixed |
People
(Reporter: Gijs, Assigned: johnmax2468, Mentored)
References
(Blocks 1 open bug)
Details
(Keywords: good-first-bug, Whiteboard: [lang=js])
Attachments
(16 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
A long, long time ago, in a galaxy far away a company called Netscape, someone decided that UI functions for the Browser
should all be prefixed Browser
and just live in the window scope as global functions.
So now we have BrowserBack
, BrowserForward
, BrowserRefresh
, and... well, you get the picture.
There are about 20 of these functions. The goal of this bug is straightforward: move those functions to their own file, as methods on a singleton object, which doesn't get loaded until one of those functions is actually called.
To do this, you'd want to:
- decide on the name of the object. I suggest
BrowserCommands
, as they're often called viacommand
elements. - create a new JS file that matches the name (but as lower-case-with-dashes, so
browser-commands.js
in my example), inbrowser/base/content/
- create a new object there using the name decided above.
- make sure the file is loaded using a lazy script getter, like so:
XPCOMUtils.defineLazyScriptGetter(
this,
"BrowserCommands",
"chrome://browser/content/browser-commands.js"
);
Of course using the object name and file name decided above. You can add the getter somewhere like here: https://searchfox.org/mozilla-central/rev/bf8c7a7d47debb1c22b51a72184d5c703ae57588/browser/base/content/browser.js#111-115
- move all the functions in the query above into the new file, inside the new object
- rename them all as methods on
BrowserCommands
, using camelCase. So e.g.BrowserBack
would look like this:
let BrowserCommands = {
back(aEvent) {
// contents of the function goes here
},
};
- update all the callers of these functions to use their new names (so
BrowserCommands.back()
orBrowserCommands.refresh
or whatever). You can find them by using case-sensitive searchfox queries. This is the one forBrowserBack
: https://searchfox.org/mozilla-central/search?q=BrowserBack%28&path=&case=true®exp=false .
Assignee | ||
Comment 1•10 months ago
|
||
Hey, I'm interested in working on this bug.
I had a quick look, and there seem to be a few functions that are used in both the Browser*
functions and other functions in browser.js
, what should be done about them?
Reporter | ||
Comment 2•10 months ago
|
||
(In reply to Yi Xiong Wong from comment #1)
Hey, I'm interested in working on this bug.
Great! Thanks for your interest in helping make Firefox better. :-)
I had a quick look, and there seem to be a few functions that are used in both the
Browser*
functions and other functions inbrowser.js
, what should be done about them?
Not 100% sure which functions you ran into, but I expect it will depend a bit on the function.
In terms of the patch "working", you could leave the called functions as-is and it would work (I think), because the lazy script getter will just load the new script file in the same global as browser.js
so if the function was available before in that same global scope, it will still be available now. The linter might complain but I think it shouldn't. I could be wrong about that though.
If you wanted to make things neater, some items could be replaced, e.g. whereToOpenLink
, getRootEvent
and a few others like it are just a forwarding function for methods that exist on BrowserUtils
or URILoadingHelper
, and could be called directly on those helpers to avoid the confusion. If you'd like to start with something a bit smaller than this bug, you could do some of that part first, in bug 1742889 - it should be more straightforward with no other dependencies.
As a different example, duplicateTabIn
is only called from Browser*
functions and goToHistoryIndex
, which could both also move into the new file together (which helps with grouping similar/related code together, as goToHistoryIndex
is only used from the back/forward buttons' menus anyway, similar to BrowserBack
and friends). FillHistoryMenu
should probably move along with those as well.
Basically, fixing this bug will require being somewhat creative with the "dependency tree" of these functions. It would probably be a good idea to split up any patches to move a few functions at a time, to help keep the problems addressed in a single patch manageable. I'm happy to help with figuring out the details if you get stuck on anything, though I also understand if now that you've looked at it you decide that this is maybe more than you wanted to take on right now. Let me know! :-)
Assignee | ||
Comment 3•10 months ago
|
||
I'm happy to help with figuring out the details if you get stuck on anything, though I also understand if now that you've looked at it you decide that this is maybe more than you wanted to take on right now. Let me know! :-)
Nah, I still want to work on this. I expected this anyways, refactoring code is never simple. :)
Reporter | ||
Comment 4•10 months ago
|
||
(In reply to Yi Xiong Wong from comment #3)
I'm happy to help with figuring out the details if you get stuck on anything, though I also understand if now that you've looked at it you decide that this is maybe more than you wanted to take on right now. Let me know! :-)
Nah, I still want to work on this. I expected this anyways, refactoring code is never simple. :)
Heya, how is this going - are you stuck on anything / is there anything I can do to help?
Assignee | ||
Comment 5•10 months ago
|
||
Hey, I'm almost done with this, just need to double check that I didn't miss anything, then I can submit the patch. These functions are used in quite a few places (and tests) so I've got to make sure those still work.
Assignee | ||
Comment 6•10 months ago
|
||
Updated•10 months ago
|
Assignee | ||
Comment 7•10 months ago
|
||
Assignee | ||
Comment 8•10 months ago
|
||
Assignee | ||
Comment 9•10 months ago
|
||
Assignee | ||
Comment 10•10 months ago
|
||
Assignee | ||
Comment 11•10 months ago
|
||
Assignee | ||
Comment 12•10 months ago
|
||
Assignee | ||
Comment 13•10 months ago
|
||
Hmm, it looks like I accidentally removed duplicateTabIn
from the globals array. How do I edit a commit to remove that change? hg histedit
gives me a warning about content divergence.
Reporter | ||
Comment 14•10 months ago
|
||
(In reply to Yi Xiong Wong from comment #13)
Thanks for the patches!
Hmm, it looks like I accidentally removed
duplicateTabIn
from the globals array. How do I edit a commit to remove that change?hg histedit
gives me a warning about content divergence.
I'm sorry, I didn't see this before reviewing the patches.
I haven't seen a warning like this before; can you provide a full log (either as attachment or in backtick "fences" (ie triple backtick) in a comment?)
The output of hg wip
(assuming you've run ./mach bootstrap
) or hg show stack
(if you haven't) may also help figuring this out. :-)
Reporter | ||
Comment 15•10 months ago
|
||
Err, I guess you figured it out based on the updates - clearing needinfo. But feel free to ping me again if you get stuck with hg
.
Reporter | ||
Comment 16•10 months ago
|
||
I'm going to land all the approved patches to avoid bitrot. :-)
Reporter | ||
Comment 17•10 months ago
|
||
(In reply to :Gijs (he/him) from comment #16)
I'm going to land all the approved patches to avoid bitrot. :-)
Err, though it looks like D205524 and later may need to be rebased because of the change to use the browser-window
env?
Comment 18•10 months ago
|
||
Comment 19•10 months ago
|
||
bugherder |
Assignee | ||
Comment 20•10 months ago
|
||
(In reply to :Gijs (he/him) from comment #15)
Err, I guess you figured it out based on the updates - clearing needinfo. But feel free to ping me again if you get stuck with
hg
.
Yup, figured it out eventually, and forgot to clear the needinfo, sorry!
(In reply to :Gijs (he/him) from comment #17)
(In reply to :Gijs (he/him) from comment #16)
I'm going to land all the approved patches to avoid bitrot. :-)
Err, though it looks like D205524 and later may need to be rebased because of the change to use the
browser-window
env?
Done, should be fine now?
Updated•10 months ago
|
Comment 21•10 months ago
|
||
Comment 22•10 months ago
|
||
bugherder |
Assignee | ||
Comment 23•10 months ago
|
||
Reporter | ||
Comment 24•10 months ago
|
||
I'm on a short break over Easter, until Tuesday, but will definitely be reviewing the new incoming patch(es) then. I pushed the existing r+ patches and those seem to have landed successfully. Thanks again for picking this up!
Assignee | ||
Comment 25•10 months ago
|
||
Assignee | ||
Comment 26•10 months ago
|
||
Assignee | ||
Comment 27•10 months ago
|
||
Assignee | ||
Comment 28•10 months ago
|
||
Assignee | ||
Comment 29•10 months ago
|
||
Assignee | ||
Comment 30•10 months ago
|
||
Reporter | ||
Comment 31•10 months ago
|
||
OK, I just finished reviewing all the new patches - thank you!
Once those are out of the way, only BrowserOpenAddonsMgr
and BrowserForceEncodingDetection
remain, I think?
For the former, could we move it to browser-addons.js
instead (perhaps as a method on BrowserAddonUI
) ? That would seem more topical.
Comment 32•10 months ago
|
||
Comment 33•10 months ago
|
||
bugherder |
Comment 34•9 months ago
|
||
Should this bug also move the BrowserSearch
object? It is used in a similar way to the Browser* functions.
Comment 35•9 months ago
|
||
(In reply to tobias from comment #34)
Should this bug also move the
BrowserSearch
object? It is used in a similar way to the Browser* functions.
That needs splitting up differently, and we have bug 1880913 filed to cover that.
Comment 36•9 months ago
|
||
Comment 37•9 months ago
|
||
bugherder |
Assignee | ||
Comment 38•9 months ago
|
||
Assignee | ||
Comment 39•9 months ago
|
||
Assignee | ||
Comment 40•9 months ago
|
||
(In reply to :Gijs (he/him) from comment #31)
OK, I just finished reviewing all the new patches - thank you!
Thanks to you too!
Once those are out of the way, only
BrowserOpenAddonsMgr
andBrowserForceEncodingDetection
remain, I think?For the former, could we move it to
browser-addons.js
instead (perhaps as a method onBrowserAddonUI
) ? That would seem more topical.
Done
Comment 41•9 months ago
|
||
Reporter | ||
Updated•9 months ago
|
Comment 42•9 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/07ae6e6eaa04
https://hg.mozilla.org/mozilla-central/rev/ccf28f25eec7
https://hg.mozilla.org/mozilla-central/rev/177f569e8625
Reporter | ||
Comment 43•9 months ago
|
||
Thanks so much for your help here, Yi Xiong Wong! If you're enjoying the code cleanup, although bug 1882774 and bug 1882776 are not marked "good first bug" and probably slightly trickier than the refactoring here, they should be very manageable after all your work here. If you'd prefer non-refactoring mentored bugs I could look for some of those, too - just let me know. :-)
Description
•