As arrow functions have an implicit return value, an assignment of
this.foo = bar could have been intended as a this.foo === bar
comparison. To catch those errors, we will disallow these kinds
of assignments unless they are marked explicitly by an extra pair
of parentheses.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/731
Calling await in a loop means the asynchronous operations are
run sequentially instead of in-parallel. Usually that's not
what's wanted, so eslint has a rule to warn about this.
However here we use async/await to handle control back to the
mainloop between steps, so running operations sequentially is
actually intended.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/731
The intention of the code is clearly to operate on a copy, but that's
not how the Object constructor works. While it doesn't matter in
practice that we modify the passed-in object parameter, it's still
a good idea to fix the code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/731
The legacy indent rule currently ignores arrow functions in parameters
to allow callbacks to not align with the other arguments:
this._someFunctionWithFairlyLongishName(arg1, arg2, arg3,
() => {
this._someOtherFunctionWithLongName(arg1);
});
But as ignoring entire nodes means we can end up with arbitrary
indentation, we should drop the exception. While this would make
the above "illegal" under the legacy config, it conforms with the
non-legacy style, so everything should be fine ...
... except that eslint starts to complain about some function args
that should be fine under the legacy config. Maybe it's thrown off
by the function-arg-in-arrow-function-in-function-arg structure, but
rather than figuring it out, let's just move those to the new style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/725
We are currently inconsistent whether to put the operators in front
of the corresponding line or at the end of the preceding one. The
most dominant style for now is to put condition and first branch on
the same line, and then align the second branch:
let foo = condition ? fooValue
: notFooValue;
Unfortunately that's a style that eslint doesn't support, so to account
for it, our legacy configuration currently plainly ignores all indentation
in conditionals.
In order to drop that exception and not let messed up indentation slip
through, change all ternary operators to the non-legacy style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/725
Some more places where the indentation doesn't comply with either
the old or new style. They slipped through because the legacy eslint
configuration accounts for some patterns by plainly ignoring certain
nodes. We'll address that later, first fix up the indentation errors.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/725
When there is a transition, it's likely that we are animating some part
of the desktop, and in such situations we don't want to unredirect
fullscreen windows.
This fixes unwanted unredirection when e.g. hiding a modal dialog by
re-enabling the unredirection after the animation has finished, instead
of when it starts.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/721
Updating the window list in the Looking Glass is a costly
operation: it destroys a whole lot of actors, and recreates
them. This triggers CSS changes, repaints, and allocations.
It is specially bad when paired with Wayland's big number
of window creations and deletions when showing Builder's
and Epiphany's popup window.
Only update the window list in the Looking Glass when it is
visible.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/556https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/719
Since ES5, it is possible to create objects with no prototype at all:
let foo = Object.create(null);
Those object won't have any builtin properties like hasOwnProperty(),
which is why eslint added a corresponding rule to its default rule set.
While this isn't an issue that affects our code, there's no harm in fol-
lowing the recommendation and call the method through Object.prototype.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/716
We currently use no less than three different ways of indenting
object literals:
let obj1 = {
foo: 42,
bar: 23,
};
let obj2 = { foo: 42,
bar: 23 };
let obj3 = { foo: 42,
bar: 23
};
The first is the one we want to use everywhere eventually, while the
second is the most commonly used "legacy" style.
It is the third one that is most problematic, as it throws off eslint
fairly badly: It violates both the rule to have consistent line breaks
in braces as well as the indentation style of both regular and legacy
configurations.
Fortunately the third style was mostly used for tween parameters, so
is quite rare after the Tweener purge. Get rid of the remaining ones
to cut down on pre-existing eslint errors.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/716
Since disabling an extension will lead to disabling and re-enabling all
following extensions in the list, always disable multiple extensions by
looping through the list in reverse order.
This lowers the execution time of the event handlers quite a bit if many
extensions are installed.
Thanks to Philippe Troin for identifying the problem and proposing the
initial patch to change the extension order when reloading.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/177https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
Only push uuids of newly enabled extensions to the `_extensionOrder`
array if enabling them was successful.
Otherwise, since `_callExtensionDisable()` doesn't remove uuids that
weren't successfully enabled from the array, those extensions get added
to the array multiple times when they're disabled and enabled.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
It's currently possible to circumvent the `sessionMode.allowExtensions`
property: For already enabled extensions one can call reloadExtension
via DBus, for new extensions it's possible by adding the extension to
the enabled-extensions gsettings key and setting the
disable-extension-version-validation key (which triggers a reload of
`this._enabledExtensions`) and then calling reloadExtension via DBus.
So to enforce `allowExtensions` while still allowing to update
extensions and keeping the extensionSystem synced with various gsettings
keys, replace the checks for `this._enabled` with simple checks for
`Main.sessionMode.allowExtensions` inside `_callExtensionInit()` and
`_callExtensionEnable()`.
The remaining checks for `this._enabled` are only small optimizations to
prevent running code on irrelevant sessionMode updates.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
Right now we're only handling added sessionMode extensions correctly on
sessionMode updates, also handle the other case and disable removed
sessionMode extensions on sessionMode updates.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
Instead of only logging a message that loading the extension stylesheet
failed and silently returning we should use `logExtensionError` for that
instead. This also sets the extension state to ERROR and makes sure we
don't try to enable it again.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
If the extension doesn't exist in the `this._extensions` Map, we'd try
to access `extension.dir` on undefined/null. So set the `dir` variable
after checking if `extension` is defined.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/96
Code and comment were based on the old get_input_rect() and get_outer_rect()
method names that were changed to the more appropriate get_buffer_rect() and
get_frame_rect() a long time ago.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/713
The animation was removed in commit 6a00a504d4 for consistency with
other menus. However commit a9b12d5d73 then *added* animations to
those just four minutes later.
So add back the original animations for consistency, both with menu
closing and with other menus.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1595
