New issue
Advanced search Search tips

Issue 868836 link

Starred by 2 users
Status: Fixed
Owner:
rbpotter@chromium.org
Closed: Jan 17
Cc:
nyerramilli@chromium.org
rbasuvula@chromium.org
manukh@chromium.org
namratakannan@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug-Regression



Sign in to add a comment

Regression: [Print Preview] 'Select a destination' overlay seems to be chopped from LHS.

Reported by dchau...@etouch.net, Jul 30 
Chrome Version: 70.0.3507.0 (Official Build) Revision	4007f2d27a020a7a7abab69f4bbb1088679bcbf8-refs/branch-heads/3507@{#1} 32/64-bit.
OS: Windows-10

Precondition : Enable #enable-new-print-preview flag from chrome://flags

What steps will reproduce the problem?
1. Launch chrome, give print command on NTP or any webpage and click on 'Change..' button under 'Destination' section.
2. Completely resize the browser from RHS to LHS and press 'Tab' key till focus reaches to 'Cancel' button.
3. Now press "Shift + Tab" key to reverse focus travel on 'Search destinations' text-box and observe.

Actual: 'Select a destination' overlay seems to be chopped from LHS.
Expected: 'Select a destination' overlay should seen properly from LHS.

This is a Win-10 specific regression issue, broken in M-70 series, below is manual regression range:

Good build: 70.0.3504.0 (Revision: 578511)
Bad build: 70.0.3505.0 (Revision: 578873)

Unable to narrow down the range using per-revision bisect, hence providing bisect using Chromium builds:

You are probably looking for a change made after 578622 (known good), but no later than 578625 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/0ef56662dea35239b28c5c7e30579af4ab09139d..5e654af86b2a1b93ec80e3ec69d29d83535e5071

Suspecting: https://chromium.googlesource.com/chromium/src/+/01a5a40f27ac01ee9ebff5cfc78e1cb66520f3d8

@manukh: 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: This issue is not observed in Windows(7, 8, 8.1), Mac(10.12.6, 10.13.1, 10.14, 10.13.6) & Linux(14.04 LTS) OS.

Kindly review the attached screen-cast for reference.

Thank you.
Overlay_Screenshot.png
80.1 KB View Download
Actual behavior.mp4
2.2 MB View Download
Expected behavior.mp4
1.7 MB View Download

Comment 1 Deleted

Comment 2 by manukh@chromium.org, Jul 30 

i am not able to reproduce the issue. Maybe it's resolved?
focus print dialog scrolling.mp4
548 KB View Download

Comment 3 by dchau...@etouch.net, Jul 31 

With response to comment #2: 
 Retested this issue on Windows-10 machine using latest Canary 70.0.3508.0 and the issue is still reproducible.

NOTE: This issue is only reproducible on Windows-10 machine.

Kindly refer the attached screen-cast for the same.

Thank you.
Canary 70.0.3508.0 behavior.mp4
2.2 MB View Download

Comment 4 by thestig@chromium.org, Aug 1

Cc: manukh@chromium.org
Components: Blink
Labels: -Pri-1 -Target-70 -M-70 Pri-3
Owner: ----
Status: Untriaged (was: Assigned)
The behavior difference depends on the minimum width allowed for a browser window. As seen in Overlay_Screenshot.png 
. The behavior on Win 10 for me is:

- Before r578623, sometimes the min width is 320 pixels, and sometimes it is 395. When the min width is 320, we get the "expected" result and when it is 395, we get the "actual" result. I don't know why the behavior is inconsistent.
- After r578623, it is harder/impossible to get the min width to be 320 pixels. Therefore we (almost?) always get the "actual" result.

There's no guarantee for what the minimum width of a window can be. It can change in the future, or vary based on the OS / font size / etc. So this issue can appear or disappear at any time. Given the severity of this issue is fairly low, I think we should:

- Lower the priority.
- Ask the Blink folks to look into why the WebUI has this quirk. When I keep pressing tab to cycle forward all the around, instead of cycling backwards, this does not happen.

Comment 5 by fs...@chromium.org, Aug 8

Components: -Blink UI>Browser>WebUI
this is probably on WebUI rather than Blink. If not, please reassign the component.

Comment 6 by thestig@chromium.org, Aug 15

Cc: namratakannan@chromium.org
I still think the Blink behavior is quirky, but we can probably work around it in WebUI.

namratakannan: Right now the select a destination dialog has a fixed width. Should the width change when the window becomes narrower?

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

Components: -UI>Browser>WebUI

Comment 8 by namratakannan@chromium.org, Sep 17 

I think the use case for making the manage destination window responsive is weak: while resizing of windows does happen, it is not normal behavior to trigger manage destination whilst on a small (<600) screens...so having a horizontal scroll is fine.

Tried this out on a Win10 and it followed expected behavior

Comment 9 by namratakannan@chromium.org, Sep 17 

So chatted with Rebekah...new Print refresh UI Manage destination dialog is already responsive. So we can move forward with that as a solution
Screenshot (93).png
1.7 MB View Download

Comment 10 by thestig@chromium.org, Jan 16 (6 days ago)

Owner: rbpotter@chromium.org
I think this is fixed, since the new Print Preview has a printer selection dialog that resizes to fit the window.

Comment 11 by cdin...@virtusa.com, Jan 17 (6 days ago) 

Update:
 Retested this issue on Windows-10 machine using latest Canary #73.0.3673.0 with the steps mentioned in description. This issue is fixed and working as expected.

Attaching screen-cast for the same.

Thank you..!
Latest Canary behavior.mp4
1.6 MB View Download

Comment 12 by rbpotter@chromium.org, Jan 17 (5 days ago)

Status: Fixed (was: Untriaged)
Marking as fixed based on comment 11. Thanks for verifying.
►

Sign in to add a comment