Before 2d95d36a8e, clicks on links inside toggles with non-empty
targets that are not '#', were ignored ("pass through") since they
are not intended for the toggle.
In 2d95d36a8e, this was simplified to ignoring clicks from all <a>
elements inside toggles. However this ignored too much as links
without 'href' attribute are also sometimes used inside toggles
to look like links and have no href-target, which means clicking
them does nothing and is in fact meant to toggle the element.
Restore previous behaviour and restore previous test + add a new
test for this specific case.
Bug: T166298
Change-Id: Ia3a0648f809f94be0977a83b469fbd184aa72aff
Module 'mediawiki.page.watch.ajax' requires a dependency to module
'mediawiki.page.startup' because 'mediawiki.page.startup' creates the object
mw.page and 'mediawiki.page.watch.ajax' requires this object.
This dependency got lost in 06a0dec057.
Bug: T114288
Change-Id: Iebfda85c77eaf6bb19d2ae755813b1c36a95dac8
(cherry picked from commit ef456a7805)
Let's deprecate the mw.page object in the same way we did with mw.special.
mw.page.watch is the only property that exists inside mw.page, and it's mostly
internal. Let's expose that via module.exports instead (for use by Wikibase
and VisualEditor).
Change-Id: I0e6a95bd4fbaba06eae5137ac7af84f62bebf6f0
The object mw.page is only used in watch.js and it is not intended to extend
this object by other modules because with module.exports exists a more
flexible way.
This change avoids the dependency on module 'mediawiki.page.startup'.
Change-Id: Ib717261c20856d048c67e2196e9dc619b72ab1db
Module 'mediawiki.page.watch.ajax' requires a dependency to module
'mediawiki.page.startup' because 'mediawiki.page.startup' creates the object
mw.page and 'mediawiki.page.watch.ajax' requires this object.
This dependency got lost in 06a0dec057.
Bug: T114288
Change-Id: Iebfda85c77eaf6bb19d2ae755813b1c36a95dac8
This avoids the public method mw.util.init().
Add a noop function and a deprecation warning to mw.util.init().
The dependency to module 'mediawiki.page.startup' is not necessary anymore
for using mw.util.$content.
Change-Id: Ib8ca3f9afa43de0ff0bb87569dd2ddfddf2a69b8
The module 'mediawiki.page.patrol.ajax' does not need a dependency on
the module 'mediawiki.page.startup'.
Change-Id: I2619a0709b93c26a8b3906273b4d5a988230d662
The naming convention remains unchainched. Default toggles are added if no mw-collapsible-toggle child element is present. Premade toggles have already one ore more mw-collapsible-toggle elements defined.
Default and premade toggles (mw-collapsible-toggle) still cannot be mixed/combined with remote toggles (mw-customtoggle).
* The default toggle got less rigid by removing dependency on <a> elements.
* Support for multiple premade toggles was introduced.
* The expand/collapse messages can be used by premade toggles via mw-collapsible-text.
* Removed the linksPassthru option. This step allowed merging premadeToggleHandler into actionHandler.
* The pass through functionality is now applied to all <a> elements since the default toggle does no longer depends on those.
* Removed mw-collapsible-bracket because it was not used and is deprecated by mw-collapsible-text.
* The test suite was adapted to reflect the latest changes.
Change-Id: Ic8627c4c185e8e4175e6fef1c8e1c2190e54edaa
Since bf69459, ApiSandbox seems to stall out when an API request
results in an HTTP error (e.g. due to a PHP fatal error). Before that
revision, it displayed the 'apisandbox-results-error' message in this
situation.
Apparently the jQuery 3 changes to Deferred behavior caused it to be
impossible to have a then() filter return `this` (or anything else) in
order to avoid replacing the existing promise that's being resolved or
rejected.
Bug: T165857
Change-Id: I3f646cdfe7fe8987437980790788821f51e728d1
When repositioning images based on the "change" event,
ignore images that have already been assigned to a row.
Bug: T163727
Change-Id: Ida7556d8848f98d97d82aef9caf5c1d43bb47d7b
Another typo in the code made highlight feature always load as false
when you loaded a saved filter.
Bug: T165437
Change-Id: I0e0efa3576659e4145b20013e4af7a06e4e7c0ff
Saved queries are storing *filter* definitions, not parameters, so
highlight state (dictating whether highlights are enabled) are supposed
to be stored as boolean.
A previous fix that was meant to make sure we store and handle all
*parameters* as strings '0' and '1' was a bit overzealous, and stored
highlight state in saved queries as '1' and '0' too. The current state
then compared that to the filter-state, which produces false/true.
This resulting in saved queries only being matched to the current
state as never true, because the comparison goes by actual obejct
key-values, not symbolic values.
Bug: T165381
Change-Id: Ifdec3a8c058a0e004304e48a857c58639928b36f
Up until now, we only populated highlights in the URL if the item had
a highlight, otherwise it was not in the url at all. However, now that
the system can load defaults from saved queries that can have highlights
themselves, then every time we reload the page (and the system checks
to get defaults merged with the URL query) nothing actively overrides
the default highlight value if it exists.
This meant that if you have a saved query default with any highlights
in it, every time you load the page from the URL it will **also add**
the default highlights that you have saved.
To prevent this, the URL now needs to always populate items with
highlight value, even if that value is null. When we literally ask
for defaults or when we actively load a saved query, that value will
be overridden, but if we have a URL with highlights enabled at all,
the defaults will not override and add a redundany unneeded highlight
just because it existed in your saved query.
Bug: T165231
Change-Id: Ia43b5c777c0b4e238e99818696a3a60dda0daca9
Because '0' is a string, it's true, but for our purposes, it's
supposed to be false. Thanks JavaScript.
This bug was actually pretty horrific, it meant that when you refresh
the representation is all wrong (all items in the group were considered
true if the group was 'send_unselected_if_any' which meant that most
of those (that are full coverage) 'corrected themselves' to be all-false
which meant you lost filters when refreshing, even though the parameters
appeared in the URL (the url helpfully corrects itself based on the model
but the model was wrong.)
How did this pass unit tests, one might ask. Well, the unit tests were
treating parameter values as numbers, rather than strings, a fact that
is promptly fixed in this commit.
Also, for consistency and proper data validation, all parameters are
now always stored and handled as strings, in the model.
Bug: T165230
Change-Id: I16d8d95be067b3e48e557ef25f8eb6a49736aa4e
Make the view model more generic and ready to accept other types
of filtering, like namespaces and tags, by handing off the responsibility
and logic of the parameterizing and filter relationships to the groups.
Change-Id: I9c333719e89088d96d044d72ddb9c39feeeb68ca
No longer hide the button when the menu is empty, but instead
show the placeholder item when the *model* is empty.
Bug: T164861
Change-Id: I96e5e375de5f35946663042f6731d7b69e53308b
Because it is empty, even if there's multiple spaces. Also, if the
input is invalid and we didn't save the query, don't close the
popup.
Bug: T165113
Change-Id: I30e68b0b90e2a4077fb4068c1462d40b03cbfe8c
The highlight parameter enables/disables the highlight view. It was
not properly updated to the URL, and a separate typo made it not update
the model correctly.
Bug: T165107
Change-Id: Ie711d4d08fb3eeffca50c2953016e02e2620f898
