Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Fwd: Detecting unused chrome and resource files - bug 1316187

9 views
Skip to first unread message

Florian Quèze

unread,
Nov 22, 2016, 5:56:22 PM11/22/16
to dev-devel...@lists.mozilla.org
This message I sent to firefox-dev also applies to devtools. I
especially need help to go through the list of unreferenced devtools
files as I'm less familiar with this part of the tree.
https://docs.google.com/spreadsheets/d/1lthM18DHQUy2Spn1IN8w-nXHjxU9ion91p996GoAH94/edit#gid=362236084

---------- Forwarded message ----------
From: Florian Quèze <flo...@queze.net>
Date: Tue, Nov 22, 2016 at 10:22 PM
Subject: Detecting unused chrome and resource files - bug 1316187
To: "firef...@mozilla.org Dev" <firef...@mozilla.org>


After extending the browser_parsable_css.js mochitest to verify that
all the files referenced from our CSS actually exist, I started
wondering if it would be possible to reverse the checks to detect the
files we are shipping but that aren't referenced anywhere. I'm
experimenting with this idea in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1316187

The general approach is to:
- list all the files and convert their paths to urls,
- parse all the code files (including the binary libxul file) to
extract chrome:// and resource:// urls,
- compare these 2 sets of urls, and report differences.

I was afraid there would be so many undetectable file references (due
to urls built using string concatenation in the code) that the result
would be useless, but the output I got from my try pushes are
promising enough to make me think this can be pushed past the current
proof of concept.

There are currently 237 files reported as potentially unused, plus 110
for devtools.
The final test will have a whitelist to cover false-positives, and we
can also whitelist a few unused files that have bugs on file, but I'll
need help to go through this long list, verify for each file if it
should be removed (and if not figure out why), and file bugs.

I created a google spreadsheet to coordinate this work:
https://docs.google.com/spreadsheets/d/1lthM18DHQUy2Spn1IN8w-nXHjxU9ion91p996GoAH94/edit

Please have a look, and help with the files in areas that are the most
familiar to you!

Thanks,
Florian

--
Florian Quèze

J. Ryan Stinnett

unread,
Nov 23, 2016, 6:26:19 PM11/23/16
to Florian Quèze, dev-developer-tools
Thanks for bringing this issue up Florian, it's great to have coverage for
this.

I've started to look into the DevTools files, but others are welcome to
help as well!

- Ryan
> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>

Jason Laster

unread,
Nov 24, 2016, 9:05:12 AM11/24/16
to Florian Quèze, J. Ryan Stinnett, dev-developer-tools
Thanks Florian.

I believe we are inlining the SVGs in the new debugger bundle and can
delete the svgs in debugger/new. I can confirm and nuke next week if that's
correct.
0 new messages