If an actor is destroyed, calling get_transformed_size()/position()
can return bogus values and trigger JS exceptions.
This can happen if a tracked actor comes from an extension
(such as classic mode's window-list) and that extension is
deactivated.
https://bugzilla.gnome.org/show_bug.cgi?id=723661
This reverts commit a36bfced47.
get_available_connections() returns the connections that are
available right now, ie, with the currently visible APs, but
that might change while the dialog is open, so we can't use it.
https://bugzilla.gnome.org/show_bug.cgi?id=709128
To distinguish the bluetooth network menu from the bluetooth
menu proper, use the device name as the label.
Also, replace Connect with "Use as Internet connection"
https://bugzilla.gnome.org/show_bug.cgi?id=709353
The design says "when a network cable is connected", not
"When a network cable is connected and the link is up and we
have an IP etc. etc." (which is what ACTIVATED would imply).
https://bugzilla.gnome.org/show_bug.cgi?id=723570
Rather than just showing "No networks", inform the user if airplane
mode is on or if wifi is off, and allow the user to change that
from the dialog (if possible).
https://bugzilla.gnome.org/show_bug.cgi?id=709128
Ideally, we should keep scanning while the dialog is open, and
stop (or reduce the frequency) when it's closed. Forcing a new
scan when the dialog is opened empty is a close approximation
and increases the probability that the user will find the AP
he needs.
https://bugzilla.gnome.org/show_bug.cgi?id=709128
If airplane mode is enabled with an HW switch, we can't turn it
off from the menu, so make the menu item insensitive and
replace it with a helpful tip.
https://bugzilla.gnome.org/show_bug.cgi?id=709685
The unredirect feature does not apply to the magnifier and it
prevents users from gaming whilst it is on so disable when magnifier
is active and allow magnifier users to game!
Bug https://bugzilla.gnome.org/show_bug.cgi?id=708985
So far we have assumed that whether or not a window is interesting
is static. In general this is the case, but as it is legal for the
underlying properties to change at any time, there are of course
offenders that actually do this (flash I'm looking at ya).
While we used the property to determine whether a window should be
tracked or not, the worst case was showing windows that should be
hidden or missing windows that should be shown.
However as we nowadays base an app's running state on the number of
interesting windows, we need to be more careful in order to avoid
ending up with running apps with no windows.
https://bugzilla.gnome.org/show_bug.cgi?id=723308
The code from shell_window_tracker_is_window_interesting() is equivalent
of MetaWindow's skip-taskbar property, so use it to avoid code duplication.
https://bugzilla.gnome.org/show_bug.cgi?id=723308
The DESKTOP window might not be located at (0,0), in particular
on multi-monitor setups. While we already consider this by setting
the clone's position, we then stuff the clone into a container which
ignores it - meh ...
https://bugzilla.gnome.org/show_bug.cgi?id=723306
