Change Details

The #german-community-wishlist team continues to run into an issue that feels more and more like it might be an actual blocker for several tasks we would like to work on, most notably {T214693}, as well as {T218765}. Steps to reproduce: When quickly hovering a link to a page, leave the link, and quickly hover it again within the time limit of less than a second, no popup will be shown. We found this is always reproducible. Chain of events: * When hovering the link for the first time, one gets a "link dwell" event, as expected. * Let the mouse quickly leave the link. This stops everything and triggers an "abandon start" event. * When the mouse re-enters the link quick enough, the next event will be a second "link dwell". This will get a new token. The new token will make the code throw this second "link dwell" away, because it happens to touch the same link as the first "link dwell" and the code acts like the first "link dwell" will still be executed. But it won't. * The "abandon start" from before was not finished yet, and did not got stopped. It triggers an "abandon end". * No popup will ever appear. Code responsible for this behavior: * https://phabricator.wikimedia.org/diffusion/EPOP/browse/master/src/actions.js$226 is the only place in the entire codebase where a new token is generated. * https://phabricator.wikimedia.org/diffusion/EPOP/browse/master/src/reducers/preview.js$37 checks if the link that triggered a "link dwell" action is different from the link that is currently present in the state. It only accepts a new token if the link is different. In the use-case described in this ticket the link is **not** different. * https://phabricator.wikimedia.org/diffusion/EPOP/browse/master/src/actions.js$246 checks if the newly generated token was accepted and is now present in the state. Because of the check above the token was **not** accepted. The interaction is not accepted as a new one, and no fetch is ever triggered. * https://phabricator.wikimedia.org/diffusion/EPOP/browse/master/src/actions.js$353 is another check for the token, this time in the "preview show" event. But this is not even relevant for this bug. There are probably several ways to fix this issue by changing one of the lines of code listed above. #patch-for-review: * https://gerrit.wikimedia.org/r/488098

The #german-community-wishlist team continues to run into an issue that feels more and more like it might be an actual blocker for several tasks we would like to work on, most notably {T214693}, as well as {T218765}. Steps to reproduce: When quickly hovering a link to a page, leave the link, and quickly hover it again within the time limit of less than a second, no popup will be shown. We found this is always reproducible. Chain of events: * When hovering the link for the first time, one gets a "link dwell" event, as expected. * Let the mouse quickly leave the link. This stops everything and triggers an "abandon start" event. * When the mouse re-enters the link quick enough, the next event will be a second "link dwell". This will get a new token. The new token will make the code throw this second "link dwell" away, because it happens to touch the same link as the first "link dwell" and the code acts like the first "link dwell" will still be executed. But it won't. * The "abandon start" from before was not finished yet, and did not got stopped. It triggers an "abandon end". * No popup will ever appear. Code responsible for this behavior: * https://phabricator.wikimedia.org/diffusion/EPOP/browse/master/src/actions.js$226 is the only place in the entire codebase where a new token is generated. * https://phabricator.wikimedia.org/diffusion/EPOP/browse/master/src/reducers/preview.js$37 checks if the link that triggered a "link dwell" action is different from the link that is currently present in the state. It only accepts a new token if the link is different. In the use-case described in this ticket the link is **not** different. * https://phabricator.wikimedia.org/diffusion/EPOP/browse/master/src/actions.js$246 checks if the newly generated token was accepted and is now present in the state. Because of the check above the token was **not** accepted. The interaction is not accepted as a new one, and no fetch is ever triggered. * https://phabricator.wikimedia.org/diffusion/EPOP/browse/master/src/actions.js$353 is another check for the token, this time in the "preview show" event. But this is not even relevant for this bug. There are probably several ways to fix this issue by changing one of the lines of code listed above. #patch-for-review: * https://gerrit.wikimedia.org/r/488098 =QA Testing can be performed on the beta cluster desktop site using the Vector skin: https://en.wikipedia.beta.wmflabs.org/. The changes this task made affected the way events flow through the system. Most especially how network requests for the preview text are issued, succeed, fail, or are canceled. Network requests are canceled in certain conditions when the user quickly dismisses a preview. The logic is holistic and complex. There are not many configurations to test: anonymous page previews 1) enabled and 2) disabled, logged in page previews 3) enabled and 4) disabled. The desktop Minerva skin could be tested but I don't think it's likely a good use of time given the coverage provided by exercising the Vector skin. In summary, I think the configurations themselves can be tersely smoke tested. Pretty much just making sure that the configurations still exist and previews can be enabled or disabled as an anonymous or logged in user. So what should be thoroughly tested? In my opinion, it's most important to explore timing on a single enabled configuration. So far as I know, there should never be a scenario where a user can hover over a link and no page preview is shown with the exception of hovering over a link on page load. Here's what I was thinking: 1. Enable page previews . 1. Open the DevTools network tab. 1. Disable the browser cache. Chromium, at least, won't abort requests coming form the cache. 1. Hover back and forth quickly over a preview. In Chromium, canceled requests are labeled and appear red. This is a good scenario to test. With this change, a preview should always be shown when ultimately resting on a link. Without this change, it was possible to rest upon the link with no preview showing. This may require several attempts. This last step where a user can dart in and out of a link to show and dismiss the preview is the timing I think that would be most valuable to explore. When the user ultimately dwells on a link, a preview should always be shown regardless of whether previous requests were canceled or not.

The #german-community-wishlist team continues to run into an issue that feels more and more like it might be an actual blocker for several tasks we would like to work on, most notably {T214693}, as well as {T218765}. Steps to reproduce: When quickly hovering a link to a page, leave the link, and quickly hover it again within the time limit of less than a second, no popup will be shown. We found this is always reproducible. Chain of events: * When hovering the link for the first time, one gets a "link dwell" event, as expected. * Let the mouse quickly leave the link. This stops everything and triggers an "abandon start" event. * When the mouse re-enters the link quick enough, the next event will be a second "link dwell". This will get a new token. The new token will make the code throw this second "link dwell" away, because it happens to touch the same link as the first "link dwell" and the code acts like the first "link dwell" will still be executed. But it won't. * The "abandon start" from before was not finished yet, and did not got stopped. It triggers an "abandon end". * No popup will ever appear. Code responsible for this behavior: * https://phabricator.wikimedia.org/diffusion/EPOP/browse/master/src/actions.js$226 is the only place in the entire codebase where a new token is generated. * https://phabricator.wikimedia.org/diffusion/EPOP/browse/master/src/reducers/preview.js$37 checks if the link that triggered a "link dwell" action is different from the link that is currently present in the state. It only accepts a new token if the link is different. In the use-case described in this ticket the link is **not** different. * https://phabricator.wikimedia.org/diffusion/EPOP/browse/master/src/actions.js$246 checks if the newly generated token was accepted and is now present in the state. Because of the check above the token was **not** accepted. The interaction is not accepted as a new one, and no fetch is ever triggered. * https://phabricator.wikimedia.org/diffusion/EPOP/browse/master/src/actions.js$353 is another check for the token, this time in the "preview show" event. But this is not even relevant for this bug. There are probably several ways to fix this issue by changing one of the lines of code listed above. #patch-for-review: * https://gerrit.wikimedia.org/r/488098 =QA Testing can be performed on the beta cluster desktop site using the Vector skin: https://en.wikipedia.beta.wmflabs.org/. The changes this task made affected the way events flow through the system. Most especially how network requests for the preview text are issued, succeed, fail, or are canceled. Network requests are canceled in certain conditions when the user quickly dismisses a preview. The logic is holistic and complex. There are not many configurations to test: anonymous page previews 1) enabled and 2) disabled, logged in page previews 3) enabled and 4) disabled. The desktop Minerva skin could be tested but I don't think it's likely a good use of time given the coverage provided by exercising the Vector skin. In summary, I think the configurations themselves can be tersely smoke tested. Pretty much just making sure that the configurations still exist and previews can be enabled or disabled as an anonymous or logged in user. So what should be thoroughly tested? In my opinion, it's most important to explore timing on a single enabled configuration. So far as I know, there should never be a scenario where a user can hover over a link and no page preview is shown with the exception of hovering over a link on page load. Here's what I was thinking: 1. Enable page previews . 1. Open the DevTools network tab. 1. Disable the browser cache. Chromium, at least, won't abort requests coming form the cache. 1. Hover back and forth quickly over a preview. In Chromium, canceled requests are labeled and appear red. This is a good scenario to test. With this change, a preview should always be shown when ultimately resting on a link. Without this change, it was possible to rest upon the link with no preview showing. This may require several attempts. This last step where a user can dart in and out of a link to show and dismiss the preview is the timing I think that would be most valuable to explore. When the user ultimately dwells on a link, a preview should always be shown regardless of whether previous requests were canceled or not.