Cargo.lock was updated by Bug 1801767. It needs to be updated a bit. I forgot to update it by cargo command. Then order of "remove_dir_all" needs to be changed.
Differential Revision: https://phabricator.services.mozilla.com/D163062
This patch implements the "block", "upgradeScheme" and "redirect" DNR
actions, plus a comprehensive set of unit tests that exercise relevant
scenarios and edge cases.
Differential Revision: https://phabricator.services.mozilla.com/D161535
This patch implements the "block", "upgradeScheme" and "redirect" DNR
actions, plus a comprehensive set of unit tests that exercise relevant
scenarios and edge cases.
Differential Revision: https://phabricator.services.mozilla.com/D161535
Depending on the test chunks on Firefox CI, we might have a test file
executed before this one that resizes the window and does not reset it.
In most cases, this isn't an issue except when we have logic to overflow
extension buttons pinned in the toolbar into the unified extensions
panel. This is what's happening here, at least for some configurations.
By making sure that the window is large enough, we should not have
overflowed extension buttons in the panel anymore. That will make the
test more robust.
Differential Revision: https://phabricator.services.mozilla.com/D162961
We have a function, OverflowableToolbar.findOverflowedInsertionPoints, whose job it is to compute
the right insertion point for a widget if the widget is being inserted into an overflowable
toolbar.
That function failed to account for the possibility that the widget was a browser action, and
would return the #defaultList instead of the #webExtList if the item was overflowing. This
patch checks the ID of the widget first, and then supplies the correct list.
Differential Revision: https://phabricator.services.mozilla.com/D162586
The WebExtension overflow list is created lazily because the panel itself is lazy, and only gets
inserted the first time it is needed. Originally, I had written a separate function `#getWebExtList()`
to do the work of forcing the WebExtension overflow list to de-lazify, and then hold a reference
to it in #webExtList.
It turns out, that's a bit of a footgun. More than once, I've used #webExtList directly, forgetting
that the value might turn out to be `null` because the list hasn't delazified yet.
In order to smooth out that rough edge, this patch makes `#webExtList` a memoizing (evalutes once,
caches the return value for subsequent calls) getter so that anything that uses it doesn't have
to worry about the lazification. The reference member is now called #webExtListRef, and I've
added documentation about how it's probably best not to use it directly.
Differential Revision: https://phabricator.services.mozilla.com/D162585
We have some internal bookkeeping within OverflowableToolbar to remember the state of things that
have overflowed, like how wide the window needs to be before they can be moved back, etc. When an
item is removed from an overflowable toolbar while overflowed, we update that internal bookkeeping
so that OverflowableToolbar doesn't accidentally try to move those items back into the toolbar
when the window becomes wide enough again.
We've added a new overflow list for extension buttons, but we weren't updating our internal accounting
when items had been overflowed into that list. This patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D162434
This makes alert take the same area as the status panel, partially
backing out the regressing bug.
.browserStack is also relatively-positioned, so this works too. I think
I didn't realize this while writing bug 1791972 because the rule was in
a UA sheet (all <stack>s are relatively positioned, apparently).
This restores the behavior when devtools is toggled vertically. On
responsive mode this still covers the top toolbar, but that was the
pre-existing behavior. Could be fixed in a follow-up with some z-index
tweaking...
Differential Revision: https://phabricator.services.mozilla.com/D162739
Ported from clangd, this still can be improved over time, but it can be landed.
This was based on the work from https://bit.ly/3TkV2N1
* The utility makes the assumption that all header are self contained!
* It only checkes `Decls` from the main translation file, where SourceLocarion is the
passed `cpp` file.
* It builds a list with all of the includes from the translation unit.
* It matches all of the `Decls` from the main translation units with definitions from the
included header files and builds a list with used header files.
* All of the includes that are not part of the matched used header files are considered
to be unused. Of course this is correct if the first assumption if followed by the coding guide,
where all of the header are self contained. Since the mozilla code base doesn't follow this approach
false positives might appear where the is the following situation:
FOO.cpp
#include <A>
#Include <B>
If header `A` defines a symbol that is used by header `B` and `B` doesn't include `A` nor
it has symbols defined that are used by `FOO.cpp` then `B` it will be marked as potentially to be removed
by the tool.
This is the limitation determined by header that are not self contained.
The limitation presented above can be fixed in the future with extra work, but it's very time expensive
during the runtime of the checker.
Differential Revision: https://phabricator.services.mozilla.com/D161583
As suggsted in code review for the previous patch, it's clearer and less
error-prone to provide getters and setters for module fields which are
represented using more than one field in the structure.
This patch changes the operation of ModuleObject::maybeAsyncEvaluatingPostOrder
to return Nothing() after the post order is cleared, rather than the magic
value ASYNC_EVALUATING_POST_ORDER_CLEARED. This doesn't make any difference to
the modules system itself but required some changes to test code expectations.
Depends on D162869
Differential Revision: https://phabricator.services.mozilla.com/D162985
