mw.storage catches errors, so we won't crash horribly when the user has
localStorage disabled / full.
Bug: T181822
Change-Id: I212994eb535b9a8fb5f6c09deaa10b16c3d7f10e
We can place them in bottom center of the toolbar buttons with
just CSS, no need to manually calculate the position (which
doesn't give the correct results if the toolbar is not visible).
Also add z-index for correct rendering inside TargetWidget,
not overlapped by the toolbar border (e.g. in the media dialog).
Bug: T174120
Change-Id: I556ddfcf252669107cf21810fbed7c9a3751e906
The popup gets hideously deformed in other cases. Getting it to work
would probably be difficult. Let's just not show it.
Bug: T170919
Change-Id: If9005e9cdea52fefab981f4c7f05f71fce99f3e8
OOjs UI Popups position themselves automatically relative to their
$floatableContainer these days.
Also added explicit `$floatableContainer: this.$element` in the config
(although not strictly needed, since the parent node is used by
default, this makes the code more robust in case we move the popup
somewhere else in the DOM).
Bug: T167751
Change-Id: Id4267fce6499a4c217f7dc1d18871c02dd078aee
Tools only setup once now, and that is during the dummy surface
phase, so we have to setup the education popups then.
Change-Id: Idf46fe42c893c0692dc442226297253074ef9bd7
If a tool had an education popup bound to it, but it was
suppressed because the user has already seen it (according to
the cookie or localStorage), then clicking that tool would
cause a JS error.
Also remove a workaround for a ClippableElement problem
that appears to be unnecessary.
Change-Id: I73a3f5f9cc1726e28e70fc545b72960afc5ac41c
