Revision Details Pop-up sometimes in wrong place
Open, Needs TriagePublicBUG REPORT
Actions

Assigned To

None

Authored By

	dom_walden
	Sep 17 2019, 9:54 AM

Description

What is the problem?

In some circumstances the Revision Details Pop-up does not appear next to the word you just clicked on. It appears at the top of the page instead.

I have only seen it happen so far with two articles (the one in the repro steps and https://en.wikipedia.org/wiki/The_Pizza_Underground in the screenshot).

I have attempted to reproduce this with other UI widget that use OOUI's PopupWidget (e.g. VisualEditors table popup), but could not.

Steps to reproduce problem

Go to https://en.wikipedia.org/wiki/Charles_Hamya
Open WWT
Under See also, click List of wealthiest people in Uganda

Expected behavior: Pop-up appears just above where you clicked
Observed behavior: Pop-up appears above Background and education

Environment

Browser: Chromium 73 on Debian Stretch, Chrome 77 on Windows 10, Edge 18 on Windows 10, Firefox 69 on Windows 10.
Version of WWT: Git commit 997016b08ed367e0a9bd47865bcb5989b8de99ee

Screenshots (if applicable):

Related Objects

Mentioned In: T228941: Add Edit Summary to Revision Details Pop-up (WWT)
Mentioned Here: T241004: WWT: Refactor the relationship between the RevisionPopupWidget, Model and Controller for clarity

Event Timeline

dom_walden created this task.Sep 17 2019, 9:54 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 17 2019, 9:54 AM

@dom_walden:

I was unable to reproduce this bug for https://en.wikipedia.org/wiki/Charles_Hamya (see screenshot below). I still think this is something we should investigate, even if I can't personally reproduce it, but it's interesting that it didn't come up for me (using Chrome 76.0.3809.132 on macOS).

Screen Shot 2019-09-17 at 11.46.09 AM.png (709×1 px, 205 KB)

ifried moved this task from New & TBD Tickets to Needs Discussion on the Community-Tech board.Sep 17 2019, 3:49 PM

I couldn't repro either, Chromium 77 on Ubuntu.

Could the "Wiki Loves Monument" geonotice have something to do with it? I don't see why it would, but that is one thing you have that Ilana and I do not.

Works correctly for me as well. Chrome 77 on Mac.

Screen Shot 2019-09-17 at 5.06.18 PM.png (927×784 px, 174 KB)

Doesn't seem to be related to Wiki Loves Monuments either (since I have it & can't reproduce it):

Screen Shot 2019-09-17 at 5.34.29 PM.png (740×1 px, 256 KB)

ifried renamed this task from Revision Details Pop-up sometimes in wrong place to Revision Details Pop-up sometimes in wrong place [small].Sep 17 2019, 11:33 PM

ifried renamed this task from Revision Details Pop-up sometimes in wrong place [small] to Revision Details Pop-up sometimes in wrong place .

dom_walden mentioned this in T228941: Add Edit Summary to Revision Details Pop-up (WWT).Sep 18 2019, 4:23 PM

Recently, I have found this in a number of places, e.g.:

@dom_walden Is this still an issue? I'm unable to reproduce the issue, but maybe you're still seeing it. Let me know. Thanks!

In T233091#5819988, @ifried wrote:

@dom_walden Is this still an issue? I'm unable to reproduce the issue, but maybe you're still seeing it. Let me know. Thanks!

I have not been able to reproduce it yet, but I wouldn't like to bet that it will never come back :)

It might have been fixed by T241004.

Okay, thanks, Dom. I'll keep it in the 'to be estimated/discussed' column for now, and we'll check in again at a later time to see if the behavior resurfaces.

Also, @Mooeypoo, do you think this issue was fixed in the process of the refactor work in T241004? Thanks!

In T233091#5820323, @ifried wrote:

Okay, thanks, Dom. I'll keep it in the 'to be estimated/discussed' column for now, and we'll check in again at a later time to see if the behavior resurfaces.

Also, @Mooeypoo, do you think this issue was fixed in the process of the refactor work in T241004? Thanks!

My professional opinion is a solid schmaybe.

The way this bug looks, this seems to suggest that there was some race condition that prevented the $floatableContainer from being placed in time. In that case, it's extremely likely that the refactor has fixed it. However, there's a slight chance that the race condition was due to an error in loading order. I doubt that this is the case because it sounds like we'd be getting that bug a lot more often if that was the case, but coming off the trail of the previous mw.Api() loading bug, I am erring on the side of caution.

I think it's safe that if this can't be reproduced, it's good to close this bug; if it comes back, it's an easy one to spot, we'll reopen it and have an investigation. For now, looks like the refactor may have fixed it by organizing the order of attachment to the DOM + $floatableContainer, so I'll stick with that.

ifried moved this task from Needs Discussion to Older: Team Work on the Community-Tech board.Mar 3 2020, 10:57 PM

	F30382558: Screen Shot 2019-09-17 at 5.34.29 PM.png
	Sep 17 2019, 9:35 PM

	F30382294: Screen Shot 2019-09-17 at 5.06.18 PM.png
	Sep 17 2019, 9:07 PM

	F30381294: Screen Shot 2019-09-17 at 11.46.09 AM.png
	Sep 17 2019, 3:49 PM

	F30380566: chrome_revision_popup_bug.png
	Sep 17 2019, 9:54 AM

Revision Details Pop-up sometimes in wrong place Open, Needs TriagePublicBUG REPORTActions