Don't fade in navigation controls in full screen mode when using keyboard
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	MingleTerminator
	Dec 8 2014, 7:30 PM

Description

Migrated from: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/989

Steps to reproduce

Go to an article with multiple images and open one of them in Media Viewer, such as this one .
Click on the full screen button to see it in full screen mode
Press the right arrow on your keyboard to go to the next image
The navigation controls fade back in, each time you click next or previous, which is distracting.

Expected behavior

When using keyboard navigation in full screen to advance to thenext image, the controls should not fade back in. They should only fade in ifthe mouse is being used -- or if a mobile device with a touchscreen is being used.

The intent of full-screen mode is to show the image by itself, uncluttered from any artifacts. Showing the navigation controls is distracting and unnecessary when using your keyboard for navigation.

Actual behavior

When using keyboard navigation in full screen to advance to thenext image, the controls fade back in.

Related Bugs

Related Changesets

Details

	Subject	Repo	Branch	Lines +/-
	Replace webkitMovementX with movementX	mediawiki/extensions/MultimediaViewer	master	+3 -3

Customize query in gerrit

Related Objects

Mentioned In: rMEXTa377b48efec0: Updated mediawiki/extensions Project: mediawiki/extensions/MultimediaViewer…
rEMMV742a3473a62c: Replace webkitMovementX with movementX

Event Timeline

In mingle on 2014-11-12 at 17:50:10, @Gilles wrote:

Probably browser-specific

In mingle on 2014-11-12 at 18:04:34, @Pginer-WMF wrote:

The issue seems to be happening only on some browsers. I agree this needs to get fixed. Removing the "design needed" tag since there is not much to add design-wise.

In mingle on 2014-11-17 at 18:30:40, @Gilles wrote:

Chrome issues a fake mousemove event when we press the arrow keys. I've read that Chrome issues such fake events in circumstances such as the page scrolling. I have a feeling this might be related to recent work on the brlow-the-fold area. I'll try to git bisect to see if there's a recent change that could help pinpoint what causes this undesirable fake event.

In mingle on 2014-11-17 at 18:49:01, @Gilles wrote:

Not caused by a recent change. I have to figure out what event or DOM change causes this. Worst case scenario we'll try to silence the mousemove handler during next/prev events.

In mingle on 2014-11-17 at 19:06:10, @Gilles wrote:

The DOM change that causes it seems to be assigning a new image... not really something we can avoid.

In mingle on 2014-11-17 at 20:49:07, @Gilles wrote:

https://gerrit.wikimedia.org/r/173915

MingleTerminator closed this task as Resolved.Dec 8 2014, 7:30 PM

Change 223517 had a related patch set uploaded (by Gergő Tisza):
Replace webkitMovementX with movementX

https://gerrit.wikimedia.org/r/223517

Restricted Application added a subscriber: Matanya. · View Herald TranscriptJul 8 2015, 7:19 AM

gerritbot added a project: Patch-For-Review.Jul 8 2015, 7:19 AM

Change 223517 merged by jenkins-bot:
Replace webkitMovementX with movementX

https://gerrit.wikimedia.org/r/223517

Tgr mentioned this in rEMMV742a3473a62c: Replace webkitMovementX with movementX.Jul 8 2015, 7:40 AM

Diffusion mentioned this in rMEXTa377b48efec0: Updated mediawiki/extensions Project: mediawiki/extensions/MultimediaViewer….Jul 8 2015, 7:40 AM

• Forrestbot added a project: WMF-deploy-2015-07-14_(1.26wmf14).Jul 8 2015, 8:00 AM

Don't fade in navigation controls in full screen mode when using keyboardClosed, ResolvedPublicActions