Page MenuHomePhabricator

Cross-wiki mark as read redirects to the page instead of actually mark as read
Closed, ResolvedPublic


On fr.Wikipedia, I had a cross wiki notification from MediaWiki wiki. It is a thank notification for which I don't need to do to the page to see the diff. My plan is to mark it as read.

I have

  1. clicked on the red icon
  2. expanded cross wiki notifications
  3. clicked on the blue dot
  4. the diff has been loaded (and notification was marked as read, but that unexpected behavior caused the lost my previous page)

I've tried to du that again, by clicking carefully on the dot. Same think happen.

I think it is because mw-echo-ui-notificationItemWidget-linkWrapper class overlaps mw-echo-ui-notificationItemWidget-markAsReadButton.

Tested on Chromium 51.0.2704.79 for Ubuntu 14.04 (64-bit).


Related Gerrit Patches:

Event Timeline

Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptJul 5 2016, 8:36 AM

Could be caused by T139114: Marking notification as read causes "TypeError: sourceModel is null"

Do you get a JS error in the console just before it navigates away?

In betalabs the clickable area for 'Mark as read' blue dot seems to be sufficient enough. Clicking directly on the blue dot marks the msg as read (Chrome 50).

There is another bug found when I was looking into this issue - T139381: [minor] When cross-wiki notifications mark as read - the flyout does not display anything; it's relatively minor since it happens when only cross-wiki notifications are present (and no locals).

Change 298814 had a related patch set uploaded (by Mooeypoo):
Prevent click propogation when clicking 'mark as read' button

This is a tentative fix; according to what I saw on @Etonkovidova computer when debugging this, it seems that the proper method is called (responding to 'onMarkAsReadButtonClick') but the link is still clicked. I think this happens because the mark-as-read button is inside the content, and the content is surrounded by a <a> link, so the button responds, but then the click is propogated.

This commit should stop the propogation by returning false on that action, but I could not reproduce this bug directly in master, so I can't verify that this stops all occurrences. In any case it seems like a good thing to have in general in that case.

Etonkovidova added a comment.EditedJul 13 2016, 8:42 PM

Presently, the bug exists in 1.28.0-wmf.8 (f9d3878) displaying (very briefly)

Uncaught TypeError: Cannot read property 'findByIds' of null

1.28.0-alpha (090b37a) (betalabs) does not show the bug.

Change 298814 merged by jenkins-bot:
Prevent click propogation when clicking 'mark as read' button

Checked in betalabs - works as expected. Marked this issue as one of the priority items to be checked in production after deploy.

jmatazzoni closed this task as Resolved.Jul 14 2016, 9:22 PM

Great job diagnosing this tricky problem @Etonkovidova!

I'm closing this ticket. @Whatamidoing-WMF, thanks for reporting originally and please let us know if you see this problem again.