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

Issue 704000 link

Starred by 1 user
Status: WontFix
Owner:
wjmaclean@chromium.org
Closed: Apr 2017
Cc:
nyerramilli@chromium.org
rbasuvula@chromium.org
mcnee@chromium.org
█ msrchandra@chromium.org
dgozman@chromium.org
█ ranjitkan@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Regression : Weird behavior of vertical scale no. units is seen in devtools.

Reported by rp...@etouch.net, Mar 22 2017 
Version: 58.0.3029.33 bbd92a163524024087600eeac86ed7fa7ffc77bb-refs/branch-heads/3029@{#350}
OS: Windows (7,8,8.1,10),Mac OS X(10.11.6,10.12.1)
URL : http://che.org.il/wp-content/uploads/2016/12/pdf-sample.pdf

What steps will reproduce the problem?
1. Launch chrome, navigate to above url and open devtools using (Ctrl+shift+I).
2. Now open emulated view and click on iron icon and then select 'Show rulers'
3. Now hover mouse cursor over vertical scale no. units and observe

Actual: Weird behavior of vertical scale no. units is seen after mouse is hovered upon them
Expected: Weird behavior of vertical scale no. units should not be seen after mouse is hovered upon them

This is regression issue, broken in ‘M 52’ and will soon update other info :
Good build:52.0.2734.0
Bad build: 52.0.2735.0

Note : Issue is not seen on Linux OS.
Actual_video.mp4
860 KB View Download
Expected_video.mp4
718 KB View Download

Comment 1 by rbasuvula@chromium.org, Mar 22 2017

Cc: rbasuvula@chromium.org
Labels: hasbisect-per-revision
Owner: wjmaclean@chromium.org
Status: Assigned (was: Unconfirmed)
Using the per-revision bisect providing the bisect results,
Good build:52.0.2734.0 (Revision:393126).
Bad build:52.0.2735.0 (Revision:393409).

You are probably looking for a change made after 393234 (known good), but no later than 393236 (first known bad).

CHANGE-LOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/5bebe91356ba278a1b86b38222fbe8939707d1ea..7d739009588058584119d03613a940c12b6e6ba5

From the CL above, assigning the issue to the concern owner

@wjmaclean : Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-Url: https://codereview.chromium.org/1964133002
Note: Able to reproduce the issue in Win 10.0 & Mac 10.12.3 and Able to reproduce in latest Canary #59.0.3047.0

Comment 2 by wjmaclean@chromium.org, Mar 27 2017

Labels: -Pri-1 -M-58 M-59 Pri-2
If this has been regressed since M52, I don't think it's Pri-1.

Comment 3 by jmukthavaram@chromium.org, Apr 5 2017 

Friendly ping!!
wjmaclean@,
Still we are able to reproduce the issue on latest Canary-59.0.3063.0 .Could you please check the issue & update the thread accordingly.
Thank you!!

Comment 4 by wjmaclean@chromium.org, Apr 5 2017

Cc: mcnee@chromium.org dgozman@chromium.org
We will look at this as time permits, but we have a long list of bugs we're working on, so I don't know exactly when we'll get to this.

dgozman@ - The CL in the bisect corrected an oversight from when we fixed propagating zoom factors to OOPIFs. Can you suggest why the scales in the video might not be receiving the zoom update? Or perhaps it's a re-sizing issue? (Resize messages travel separately from zoom factor ones at present ...)

Comment 5 by dgozman@chromium.org, Apr 5 2017

Status: WontFix (was: Assigned)
I don't think this is worth fixing: pdfs are not supported on mobile and in emulation mode.
►

Sign in to add a comment