Activating a dialog is slightly different from opening it; the
former is about showing the user authentication widgetry, while
the latter is about creating it and pre-allocating the necessary
resources.
Activate the screen shield dialog when necessary.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
Since the wiggle effect will be used by the redesigned prompt-dialogs
and we always want to use the same parameters, move those as defaults
for the wiggle function to the util.js file.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/942
Use the new StPasswordEntry for password entry fields
and remove all direct handling of clutter text of the entry
via clutter_text_set_password_char to show/hide the password
text. StPasswordEntry will provides a peek-password-icon which
will allow to show/hide the password present in the field to
the user in subsequent commits.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
Since ES5, trailing commas in arrays and object literals are valid.
We generally haven't used them so far, but they are actually a good
idea, as they make additions and removals in diffs much cleaner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
ES6 allows to omit property names where they match the name of the
assigned variable, which makes code less redunant and thus cleaner.
We will soon enforce that in our eslint rules, so make sure we use
the shorthand wherever possible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
Every since commit aa394754, StBoxLayout has supported ClutterActor's
expand/align properties in addition to the container-specific child
properties. Given that that's the only container left with a special
child meta, it's time to fully embrace the generic properties (and
eventually remove the child meta).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/780
Remove the `this.actor = ...` and `this.actor._delegate = this` patterns in most
of classes, by inheriting all the actor container classes.
Uses interfaces when needed for making sure that multiple classes will implement
some required methods or to avoid redefining the same code multiple times.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/559
We now have everything in place to replace Tweener for all animatable
properties with implicit animations, which has the following benefits:
- they run entirely in C, while Tweener requires context switches
to JS each frame
- they are more reliable, as Tweener only detects when an animation
is overwritten with another Tween, while Clutter considers any
property change
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/22
The different units - seconds for Tweener and milliseconds for
timeouts - are not a big issue currently, as there is little
overlap. However this will change when we start using Clutter's
own animation framework (which uses milliseconds as well), in
particular where constants are shared between modules.
In order to prepare for the transition, define all animation times
as milliseconds and adjust them when passing them to Tweener.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/663
While we aren't using those destructured variables, they are still useful
to document the meaning of those elements. We don't want eslint to keep
warning about them though, so mark them accordingly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
Those unused arguments aren't bugs - unbeknownst to eslint, they all
correspond to valid signal parameters - but they don't contribute
anything to clarity, so just remove them anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/627
Braces are optional for single-line arrow functions, but there's a
subtle difference:
Without braces, the expression is implicitly used as return value; with
braces, the function returns nothing unless there's an explicit return.
We currently reflect that in our style by only omitting braces when the
function is expected to have a return value, but that's not very obvious,
not an important differentiation to make, and not easy to express in an
automatic rule.
So just omit braces consistently as mandated by gjs' coding style.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
While we have some style inconsistencies - mostly regarding split lines,
i.e. aligning to the first arguments vs. a four-space indent - there are
a couple of places where the spacing is simply wrong. Fix those.
Spotted by eslint.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/608
We are currently inconsistent with whether or not to put a space
after catch clauses. While the predominant style is to omit it,
that's inconsistent with the style we use for any other statement.
There's not really a good reason to stick with it, so switch to
the style gjs/eslint default to.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/607
Since version 1.50.0, gjs defines GObject.NotImplementedError for throwing
errors when a "virtual" method that requires a subclass implementation is not
defined.
So use this instead of a generic JS Error in such cases.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/549
Instead of just passing a scale when getting a cached icon, pass both a
'paint_scale', the scale of which the icon will be painted on the
stage, and a 'resource_scale', the scale of the resource used for
painting.
In effect, the texture size will use the scale 'paint_scale * resource_scale'
in a ceiled value while the size of the actor will use 'paint_scale' when
determining the size.
this would load a bigger texture, but the downscaling would keep the visual
quality.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5https://bugzilla.gnome.org/show_bug.cgi?id=765011
Certain keybindings should continue to work even when a popup
menu is on screen. For instance, the keybinding for showing
the app menu and the keyinding for showing the calendar are
examples.
This is achieved by putting in place a special "POPUP" action
mode, whenever a popup menu is active. This mode replaces
the (e.g., "NORMAL" or "OVERVIEW") action mode that was in place
for as long as the popup menu is active.
But those keybindings should not work when the user is at the
unlock dialog (which uses an action mode of "UNLOCK").
Unfortunately, since commit c79d24b6 they do.
This commit addresses the problem by forcing the action mode
to NONE at the unlock screen when popups are visible.
CVE-2019-3820
Closes https://gitlab.gnome.org/GNOME/gnome-shell/issues/851
In order to replace GTK+'s GtkDirectionType. It's bit-compatible with it,
too. All callers have been updated to use it.
This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
In order to replace GTK+'s GtkPolicyType. It's bit-compatible with it, too.
All callers have been updated to use it.
This is a purely accessory change in terms of X11 Display usage cleanup,
but helps see better what is left.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/317
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
When in lockscreen mode there's no point of resetting the auth login as there's
no welcome screen, and that would just cause the UI to freeze, with no reason.
This could have been useful if we were stopping the user to login for a given
time after ALLOWED_FAILURES attempts, but this is not the case yet.
When we get a reset signal the preemptiveAnswer should be also unset or it will
be used next time the user authPrompt will be activated, even without any further
user interaction.
Fixes#311
The _blockTimedLoginUntilIdle method sets a timeout to be called after
the user is idle for 5 seconds. That timeout is erroneously given the
source name "[gnome-shell] this._timedLoginAnimationTime" which looks
like a copy-and-paste mistake. The original intention was probably to
use a source name of "[gnome-shell] this._timedLoginIdleTimeOutId" which
more closely matches existing convention for source names.
This commit fixes that.
Make sure the focus isn't grabbed right after user interaction starts a
new timed login. Only grab it after the idle timeout is done and on the
first run instead.
Normally, we give the user a 5 second grace period of inactivity before
starting a timed login operation. Unfortunately, that grace period
timeout isn't properly removed if the timed login operation is restarted
during the grace period. That means the timeout handler can
inadvertently get called multiple times leading to the grace period
duration getting subtracted from the total animation time more than
once.
This commit ensures we only ever have one grace period timeout scheduled
at a time.
The timed login feature currently cancels the timed login operation when
a user presses a key but, oddly, only hides the indicator when the user
releases the key. This means that if a user holds down a key that
doesn't key repeat, the timed login indicator will continue to run after
the timed login operation is cancelled.
This commit address the problem by ensuring the timed login indicator is
hidden on any key press event, at the same time the timed login
operation is canceled.
When not using arrow notation with anonymous functions, we use Lang.bind()
to bind `this` to named callbacks. However since ES5, this functionality
is already provided by Function.prototype.bind() - in fact, Lang.bind()
itself uses it when no extra arguments are specified. Just use the built-in
function directly where possible, and use arrow notation in the few places
where we pass additional arguments.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
Right now we emit session-activated any time the bullet
moves in the session menu. That includes at startup when
picking an item arbitrarily, and any time GDM reports the
session was read from the user's account settings.
session-activated informs GDM about the newly selected session,
so emitting it in response to GDM reporting a session is a
bad idea.
This commit changes the code to only emit session-activated when
the user explicitly activates a session item from the gear menu.
Note, we no longer set the active session explicitly at start up.
This is a good thing since the item we were picking wasn't
necessarily correct. It does means if GDM fails to inform us
about the correct default session we'll now show no bullet instead
of a bullet on the wrong item.
https://bugzilla.gnome.org/show_bug.cgi?id=740142
gnome-shell currently initiates an automatic login attempt if
timed login is enabled and the timed login animation completes.
Unfortunately, if animations are disabled (as is the case for
virtual machines) then the timed login animation will complete
instantly, and timed login will proceed immediately after gnome-shell
has noticed the user is idle for 5 seconds.
This commit addresses that problem by initiating timed login and the
animation from a main loop timeout, instead of using the tweener api.
Any symbols (including class properties) that should be visible
outside the module it's defined in need to be defined as global.
For now gjs still allows the access for 'const', but get rid of
the warnings spill now by changing it.
https://bugzilla.gnome.org/show_bug.cgi?id=785084
While we've always considered it good style to initialize JS properties,
some code that relies on uninitialized properties having an implicit
value of 'undefined' has slipped in over time. The updated SpiderMonkey
version used by gjs now warns when accessing those properties, so we
should make sure that they are properly initialized to avoid log spam,
even though all warnings addressed here occur in conditionals that
produce the correct result with 'undefined'.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
The user list uses the same indication for hover and focus, so it
is possible for two items to be highlighted at the same time. Using
different styling would improve the situation, but only to some
extent - the user would still need to figure out which highlight
corresponds to which activation method. So instead, copy the
approach we use in popup menus and use a single property for
highlights that is updated by both focus- and hover changes.
https://bugzilla.gnome.org/show_bug.cgi?id=772284
Some PAM modules say "Press enter to continue" or
whatever. We need to support them.
This commit allows empty responses to PAM questions,
but still requires a non-empty response for username.
https://bugzilla.gnome.org/show_bug.cgi?id=784360
If the user fails to enter their password then hits escape, we
jump back to the user list, then ask again for a password in a
garbled screen. this commit fixes that by skipping a retry if
the operation is cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=784361
If the user fails to enter their password then hits escape, we
jump back to the user list, then ask again for a password in a
garbled screen. this commit fixes that by guarding against the retry
if the fail counter is reset.
We rely on the service to detect whether a fingerprint reader is
present. It is fine to not support fingerprint authentication
when the service is missing, but currently we don't handle this
case at all and end up with a non-functional login screen.
https://bugzilla.gnome.org/show_bug.cgi?id=780063
It's weird if after you select a username from the user list, there's
a password already filled in.
This commit disables at that feature for the login screen
(but keeps it in tact for the unlock screen)
https://bugzilla.gnome.org/show_bug.cgi?id=766139
When the user gets long failure messages from pam, the authPrompt
message label will clip the message and ellipsize with '…'.
This commit turns off ellipsization from the label, so it will
properly wrap.
https://bugzilla.gnome.org/show_bug.cgi?id=764445
If the user clicks Not Listed? to enter ask for username mode, clicks
cancel, and then attempts to log in via the user list, the user will see
"Authentication failed" after correctly typing the password, and then
will become stuck in an empty screen with just the gray noise background.
The problem is, we forgot to disconnect from the signal that's waiting
for the next button to be pressed on the username entry screen. Since
the signal handler that executes here is expecting the username to be
input, and isn't prepared for us to have switched back to user list,
various bad things happen. We try to start two gdm-password
conversations at once, for instance, one using the user's password as
the username. I stopped investigating here, because it's easy to fix by
disconnecting from the signal at the right time.
https://bugzilla.gnome.org/show_bug.cgi?id=770328
The Next and Sign In buttons are disabled when the username/password
field is empty. However, the user can still bypass this button by
pressing the enter key, leading to some odd glitches with the log in
for 'Not Listed?' users.
This is easy to fix by simply not progressing to the next screen when
the button is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=746180
Generally a user-changed operation will be uninteresting, but if the
user is currently in the user list and the account changes to locked, we
want to remove it from the list, or if the user is not in the list and
the account changed to unlocked, we want to add it to the list. This
fixes the case where a new user account created in gnome-control-center
does not appear in the user list. The password mode is set in the new
account immediately after it is created, but the operations are not
atomic, so the login dialog considers the new user account when it is
still locked and rejects it from being displayed, then immediately
afterwards the account is unlocked. This commit causes the login dialog
to show the account when this occurs.
The containsUser() check here is not strictly necessary, but reduces
spurious calls to addUser() and removeUser(), since there's no easy way
to check if the locked status of the account has changed (as it's much
easier to connect to one signal on the UserManager than to
notify::locked on each User object).
https://bugzilla.gnome.org/show_bug.cgi?id=758568
LoginDialog has a private _user, but UserListItem has a public user.
Easy to get wrong since _user would be the right thing to type in 90% of
this file.
