New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 718344 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Dec 10
Cc:
aee@chromium.org
nyerramilli@chromium.org
dbeam@chromium.org
█ scottchen@chromium.org
█ msrchandra@chromium.org
michae...@chromium.org
█ ranjitkan@chromium.org
dpa...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression : Weird flickering of the content within frame is seen on Back navigation of chrome://settings/content/protectedContent

Reported by abom...@etouch.net, May 4 2017 
Chrome Version:60.0.3088.3 (Official Build)  49d525d4dafb21903d1cd21025174928a3fdde75-refs/branch-heads/3088@{#4}
OS: Win(7,8,10),Mac (10.12.3,10.11.6),Linux

Pre-condition: Select 'Right-to-left direction of #force-ui-direction flag.

What steps will reproduce the problem?
1. Launch chrome and navigate to chrome://settings/content/protectedContent
2. Click on Back arrow beside Protected Content tittle for back navigation and observe.

Actual: Weird flickering of the content within frame is seen.
Expected: Flickering of the content within frame should not be seen.

This is regression issue, broken in ‘M 59’ and below is manual bisect:
Good build:59.0.3069.0
Bad build:59.0.3070.0

Note: Above issue is seen for ‘ Images’, ‘Popups’, Background sync’, Automatic downloads’, Unsandboxed plug-in access’, ‘Handlers’, ‘MIDI devices’,’Zoom levels’, ‘USB devices’,’PDF documents’, ‘Protected Content’.
Actual.mov
2.0 MB Download
Expected.mov
2.0 MB Download

Comment 1 by brajkumar@chromium.org, May 4 2017

Labels: hasbisect-per-revision
Owner: dpa...@chromium.org
Status: Assigned (was: Unconfirmed)
Using per revision bisect providing bisect information below

Bisect Information:
--------------------
You are probably looking for a change made after 464084 (known good), but no later than 464085 (first known bad).

Change Log URL:
https://chromium.googlesource.com/chromium/src/+log/8588407dac066cab5eac58b342b9ebd4f75bc848..f6d9d3d52ed411f5c39948cbb48969f1ccf41192

From the above change log suspecting below change
Review URL: https://codereview.chromium.org/2813033004

dpapad@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

Comment 2 by dpa...@chromium.org, May 4 2017

Cc: dbeam@chromium.org
Labels: Proj-MaterialDesign-WebUI
I am wondering if this is related (or duplicate) to  issue 715509 .

Comment 3 by dpa...@chromium.org, May 4 2017

Cc: scottchen@chromium.org michae...@chromium.org
I am able to reproduce the scroll position jumping around a bit during the animation, but not the flickering. I verified that commenting out [1] where it focuses an element while the animation is in progress, fixes the issue (but regresses the desired a11y behavior).

+michaelpg, scottchen: This is one more example of how our current page transition design is insufficient. There are no clear signals of when a page is exited/entered to hook up to. The code currently uses settings-animated-pages irons-elect event, which fires when a page is selected, but apparently the animation is still in progress. Trying to focus() an element while an "exit" animation still happening is causing the weirdness.

I don't have any easy fix in mind given the current design. If we were to refactor this code, providing clear enter/exit signals would be a new requirement.

[1] https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/settings_page/settings_animated_pages.js?l=88

Comment 4 by dpa...@chromium.org, May 4 2017 

Also the fact that when we initiate the slide transition, the scroll position is being reset is also contributing the the problem being reported here (see screencast).
scroll_being_reset.mp4
631 KB View Download

Comment 5 by dpa...@chromium.org, May 8 2017

Labels: Hotlist-MD-Settings-Navigation

Comment 6 by dpa...@chromium.org, Oct 24 2017

Owner: ----
Status: Available (was: Assigned)
Marking bugs (mostly lower priority ones) that I am unlikely to get to soon as Available.

Comment 7 by dpa...@chromium.org, Jul 12

Cc: aee@chromium.org

Comment 8 by dpa...@chromium.org, Dec 10

Status: WontFix (was: Available)
This no longer happens after r615011.
►

Sign in to add a comment