Changes:
* Add an ADR for using ADRs (added by `adr init`).
* Add an ADR for containing and managing state.
Change-Id: I12478ea7154c4f21204630cebdbfa18b8c0d6ba6
Changes:
* Make grunt:qunit run all QUnit tests in those modules whose names
being with "ext.popups".
* Add ext.popups/index.js, which initialises the mw.popups namespace.
* Add ext.popups/userSettings.js, which contains the code that deals
with interacting with the User Agent's storage.
* Add ext.popups/experiment.js, which contains the code that that
decides whether or not the user is in the experiment condition.
* Add tests for both units, converting existing tests where appropriate.
* Remove the associated code from ext.popups.core/ext.popups.core.js.
* Finally, dispatch the BOOT action against the store in
ext.popups/boot.js.
Change-Id: I697207677304bd49c7cfe1d37bb0a4af7810f387
Also, fix a bug introduced in Ib7168217 wherein the non-existent
Redux.thunk was referenced rather than ReduxThunk.default.
Change-Id: Ia4cc28b16b17442de69ed84bb8e8c88a6a9f201d
Changes:
* Create the ext.popups.lib module, which contains redux@3.6.0 and
redux-thunk@2.1.0.
* Rely on the Resource Loader's minification and mangling (?)
mechanisms.
* Create an asynchronous bootstrap script, which creates a Redux store
when the User Agent is idle.
Change-Id: Ib7168217a5673bb2a8378eb30d6aa45043c66e62
We should endeavour to define Resource Loader modules in one place,
extension.json. Adding them to the output, however...
Changes:
* Remove ResourceLoaderRegisterModules hook handler.
* Move all dependencies, messages, templates, and styles into "empty" RL
module definitions in extension.json so that they don't have to be
looked up later.
Change-Id: I7ec963e3296de8f411e90079ab13b97c6eba4916
You can use `grunt watch` now!
Changes:
* Re-enable QUnit (but ignore legacy tests)
* Add a sample QUnit test
* Add ability to run QUnit via `grunt watch` or `grunt test`
* Move linting to `grunt lint` task
* Add Redux to globals in linter
Change-Id: Ie4a65a8a66773d6472b3d73257267d18027ff3c3
There is one reference to removeTooltips in
ext.popups.targets.desktopTarget.
I suspect this got broken in a rebase. It seems Jenkins only runs
browser tests post merge. We should fix that.
Please resubmit the patch with this amended.
This reverts commit 0ff40a6532.
Change-Id: Idd8dffb853db760ebc5866190d008f173e3025ba
Tooltips are intended to be stripped upon `mouseenter` and `focus`
events and then restored during their corresponding `mouseleave` and
`blur` events. This was broken due to duplication of event registration
and no proper deregistration.
Changes:
* Rename `mw.popups.removeTooltips` to `mw.popups.removeTooltip` to
more accurately describe its effect
* Narrow the scope of `mw.popups.removeTooltip`
* Add `mw.popups.restoreTooltip`
* Add `onLinkBlur` to `desktopTarget.js` to handle tooltip restoration
* Update qunit test to reflect changes to functions
* Minor hygiene changes regarding event namespaces
Bug: T142723
Change-Id: I776a72e436ac823fdd6b68435d9a042a91c934e5
If a user has hovercards disabled, when they right click a link
this will trigger another hover event which will reset dwellStartTime.
This means when a dwelledButAbandoned event fires shortly afterwards
the totalInteractionTime will not be correct.
To remedy this, the calculation of totalInteractionTime and
perceivedWait is moved into ext.popups.schemaPopups
Now that we can trigger events without logging to the server and
checking the total interaction time duration in two places,
let's always run the event and only check it once.
A `hover` event triggers the setting of a dwell start time
A `display` event triggers the setting of the perceivedWait value
* Both are reset on a dwelledButAbandoned.
Since dwellStartTime is controlled inside a single place, getMassageData
no longer needs to clear it.
The test "returns false if dwelledButAbandoned event without a dwellStartTime"
is removed as this should no longer be possible.
Bug: T147846
Change-Id: Ie5917ca86f0d0ab27f4cf507e6dfa2c271433c03
This adds two new events "display" and "hover" which are not
recorded back to the server. The benefits of having these events
is that they are important events in the lifecycle of a hovercard.
This allows us to debug trackSubscribe and ensure we see the behaviour
we expect to see and in a future patchset will allow us to use these
events to drive the calculation of interaction time in one single location
(Sneak preview:
https://gerrit.wikimedia.org/r/316481 to get a feel for the why.)
Change-Id: I58eefc29444179fd245cfd722093dedea19455e8
I plan to track events that will not be logged by the schema so
am dropping the 'schema' from the topic name.
This will allow us to track events that we do not log via the schema
Change-Id: I0c2762f7ed6e54fff765513b2c2d32f73fe8902f
The Hovercards checkbox on the beta preferences page doesn't have an ID
anymore. It has a name though, which is used from now on.
The regression was introduced in I8636f32330e23814ba3b4c0f5e22e55aaf77883e.
Bug: T148856
Change-Id: I7baa78b0d8c560ee29c3a550628bfd47cad1c30e
Since DWELL_EVENTS_MIN_INTERACTION_TIME is always
zero the check will always be true so let's not make
that check unnecessarily.
We might change this in future is not a good reason
for keeping this code.
Change-Id: I23cb7ef9caeb3df470ccf109b815c4c566b0a735
Given we currently have modules defined in extension.json and in hooks
it can be really confusing understanding how the code fits together.
This change hopefully makes this a little clearer by using folder names
that are named after the resource loader modules - this is also consistent
with how we do things in our other extensions.
A images folder is added to the route so that it is clearer that the images
are not used in ResourceLoader module definitions and are only used to illustrate
the beta feature.
Change-Id: Ia650ec03e3a6d3069165441ddfa069d390be4d10
* Make it clearer what event is being bound, consistent with
onLinkClick and onLinkAbandon
* Don't create event data twice
* Refactor to reduce function size
Change-Id: Ie4368531612a2829ad191629410ba548eadb2007
Per T143051, hovercards was asked to be closed after the user clicks on
the hovercard (or the link that showed it). Closing the popup before
logging the `click` event causes `logData` to be lost. This patch logs
the data first and then clears it.
The regression was introduced in Ifd6f75c2a53d8d7b5ef9fd3f232f85b55eea24c8.
Also do not attempt closing a popup when it may not be open.
Bug: T146934
Change-Id: I02febc83036130bcea0a769114c9126cb481bafe
Per T143051, hovercards was asked to be closed after the user clicks on
the hovercard (or the link that showed it). Doing so before logging the
`dismiss` event caused `logData` to be lost. This patch logs the data first
and the clears it.
The regression was introduced in I3f3c4780cc31dc8d84cdd76df2c77fa45fbea882
Bug: T146927
Change-Id: Ie965d43b04962b2dbe2d15caa4c14bf62d1e39ea
The dismiss event is currently a side effect of closing a popup.
This should be more closely coupled with the event that causes it.
This allows the closePopup method to be called without trigging
an event which is a necessary precursor to closing popups when
navigating away from the page.
Change-Id: I3f3c4780cc31dc8d84cdd76df2c77fa45fbea882
The parameter types are incorrect and this leads to confusion
Use $ prefix for $link parameter to make clear it is a jQuery.Object
Change-Id: I3f98f3729cd06aedd791e7503233082c1402dc95
