Regression: [Print Preview] Printer name appears to be chopped under 'Destination' section.
Reported by
dchau...@etouch.net,
Nov 28
|
||
Issue descriptionChrome Version: 72.0.3624.0 (Official Build) Revision ecf0ae78590173baab05059a89e855b6813588dd-refs/branch-heads/3624@{#1} (32/64-bit) OS: Windows(7,8,8.1,10) & Linux(14.04 LTS). Pre-condition: Network printer must be selected under 'Destination' section. What steps will reproduce the problem? 1. Launch Chrome and give print command on any webpage. 2. Click on on 'More settings' button and press 'Tab' key till focus reaches to 'Background graphics' checkbox under 'Options' section. 3. Now press "Shift + Tab" key to reach the focus at 'Cancel' button and observe the printer name under 'Destination' section. Actual: Printer name doesn't seen properly under 'Destination' section. Expected: Printer name should seen properly under 'Destination' section. This is a regression issue, broken in M-72 series, below is manual regression range: Good build: 72.0.3583.0 (Revision: 600164) Bad build: 72.0.3584.0 (Revision: 600616) You are probably looking for a change made after 600222 (known good), but no later than 600223 (first known bad). CHANGELOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/5628afccb6a2d9901e9aff2c485a4a6c2de5316e..62f2f8f209a82db0dd5a311eb4f844bddb75c98e Suspecting: https://chromium.googlesource.com/chromium/src/+/62f2f8f209a82db0dd5a311eb4f844bddb75c98e @xlou: 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. NOTE: 1. This issue is also reproducible on Dev #72.0.3622.0 2. This issue is not reproducible on Mac(10.13.1, 10.13.6, 10.14.2) OS. Kindly review the attached screen-cast for reference. Thank You..!
,
Nov 28
Bisect seems wrong, will try to re-run later today. Looking at the settings page, we don't necessarily force scrollable content to scroll all the way back to the 0 position when the user moves focus to an element before it, so this may be a WontFix.
,
Nov 28
Looked into this more, and it is possible to get the "Actual" behavior in earlier builds, or the "Expected" behavior in later builds, based on the size of the browser window and the number of options in Print Preview. For the specific size being tested in the videos above, the pages per sheet feature being added likely shifted the scrolling slightly. The full control button ("Change") should always be visible when it is focused, but beyond that the scroll position seems to be determined by Blink, and is not guaranteed.
Since this is not a regression, we do not scroll the sidebar when the user tabs from the last option to the "Cancel" button, and other pages seem to work the same way, closing this as WontFix.
|
||
►
Sign in to add a comment |
||
Comment 1 by thestig@chromium.org
, Nov 28