Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1616813002:
Consider Zoom factor when getting bounding rect. (Closed)
DescriptionConsider Zoom factor when getting bounding rect.
BUG=579007
Committed: https://crrev.com/126e210435ab183a1cb2000b78379cf71aac94fd
Cr-Commit-Position: refs/heads/master@{#372588}
Patch Set 1 #
Total comments: 2
Patch Set 2 : per yosin@'s comment. #Patch Set 3 : add a test. #
Total comments: 2
Patch Set 4 : fix the test. #Patch Set 5 : #
Total comments: 3
Patch Set 6 : add TODOs. #
Messages
Total messages: 33 (6 generated)
shuchen@chromium.org changed reviewers: + yosin@chromium.org
yosin@, can you please take a look whether this makes sense to fix crbug.com/579007? Thanks
https://codereview.chromium.org/1616813002/diff/1/third_party/WebKit/Source/w... File third_party/WebKit/Source/web/mac/WebSubstringUtil.mm (right): https://codereview.chromium.org/1616813002/diff/1/third_party/WebKit/Source/w... third_party/WebKit/Source/web/mac/WebSubstringUtil.mm:116: float scale = frameView->frame().pageZoomFactor() * frameView->frame().textZoomFactor(); Which coordinate space do you want to get? See http://www.chromium.org/developers/design-documents/blink-coordinate-spaces We may want to use coodinate space conversion function |FrameView|.
https://codereview.chromium.org/1616813002/diff/1/third_party/WebKit/Source/w... File third_party/WebKit/Source/web/mac/WebSubstringUtil.mm (right): https://codereview.chromium.org/1616813002/diff/1/third_party/WebKit/Source/w... third_party/WebKit/Source/web/mac/WebSubstringUtil.mm:116: float scale = frameView->frame().pageZoomFactor() * frameView->frame().textZoomFactor(); On 2016/01/26 03:44:17, Yosi_UTC9 wrote: > Which coordinate space do you want to get? > See http://www.chromium.org/developers/design-documents/blink-coordinate-spaces > > We may want to use coodinate space conversion function |FrameView|. Done. Will the new change work?
Code changes itself is reasonable. Does this change bubble's position mentioned in crbug.com/579007? If so, please add a test file and finalize this patch.
On 2016/01/27 05:15:54, Yosi_UTC9 wrote:
> Code changes itself is reasonable.
> Does this change bubble's position mentioned in crbug.com/579007?
> If so, please add a test file and finalize this patch.
Thanks.
I'm not familiar with blink. I just added a test in WebViewTest in the latest
patch.
But the test fails at line 3207, due to the string rect getting from range is
not correct.
Per my log at line 117 of WebSubstringUtil.mm, it outputs:
=====stringRect: 13,8,1,1
which is weird, and seems because of the test isn't fully setup as the real
case.
Do you have any ideas about the test?
yosin@chromium.org changed reviewers: + keishi@chromium.org
I'm not familiar with Mac. +keishi@, who is an expert of Mac.
https://codereview.chromium.org/1616813002/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/web/tests/WebViewTest.cpp (right): https://codereview.chromium.org/1616813002/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/web/tests/WebViewTest.cpp:3194: WebView* webView = m_webViewHelper.initializeAndLoad(m_baseURL + "content_editable_populated.html"); Looks like the font size is 1px because the default font size isn't set. Add this here: webView->settings()->setDefaultFontSize(12);
https://codereview.chromium.org/1616813002/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/web/tests/WebViewTest.cpp (right): https://codereview.chromium.org/1616813002/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/web/tests/WebViewTest.cpp:3194: WebView* webView = m_webViewHelper.initializeAndLoad(m_baseURL + "content_editable_populated.html"); On 2016/01/27 13:08:39, keishi wrote: > Looks like the font size is 1px because the default font size isn't set. > > Add this here: > webView->settings()->setDefaultFontSize(12); Thanks, keishi@. Now I want to test for page is zoomed (e.g. by Ctrl+"+"). How can I make the web view zoom'ed? Is it setZoomLevel() or setTextScaleFactor()?
setZoomLevel is whats used for the zoom in the hamburger menu.
keishi@ & yosin@, can you please review this cl? Thanks Btw, I've changed this cl for commit.
Description was changed from ========== [Not-To-Commit] Consider Zoom factor when getting bounding rect. BUG=579007 ========== to ========== Consider Zoom factor when getting bounding rect. BUG=579007 ==========
https://codereview.chromium.org/1616813002/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/web/mac/WebSubstringUtil.mm (right): https://codereview.chromium.org/1616813002/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/web/mac/WebSubstringUtil.mm:116: IntRect stringRect = frameView->contentsToRootFrame(createRange(range)->boundingBox()); According to the comment boundingRect considers css transforms. Did you need to change it to boundingBox?
https://codereview.chromium.org/1616813002/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/web/mac/WebSubstringUtil.mm (right): https://codereview.chromium.org/1616813002/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/web/mac/WebSubstringUtil.mm:116: IntRect stringRect = frameView->contentsToRootFrame(createRange(range)->boundingBox()); On 2016/01/29 05:49:14, keishi wrote: > According to the comment boundingRect considers css transforms. Did you need to > change it to boundingBox? If using boundingRect, the result is wrong for zoom'ed page. How can I verify wether boundingBox can work well with css transforms?
https://codereview.chromium.org/1616813002/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/web/mac/WebSubstringUtil.mm (right): https://codereview.chromium.org/1616813002/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/web/mac/WebSubstringUtil.mm:116: IntRect stringRect = frameView->contentsToRootFrame(createRange(range)->boundingBox()); On 2016/01/29 at 05:57:59, Shu Chen wrote: > On 2016/01/29 05:49:14, keishi wrote: > > According to the comment boundingRect considers css transforms. Did you need to > > change it to boundingBox? > > If using boundingRect, the result is wrong for zoom'ed page. > > How can I verify wether boundingBox can work well with css transforms? Add CSS property "-webkit-transform", e.g. -webkit-transform: rotate(45deg) https://developer.mozilla.org/en-US/docs/Web/CSS/transform
On 2016/01/29 06:30:53, Yosi_UTC9 wrote: > https://codereview.chromium.org/1616813002/diff/80001/third_party/WebKit/Sour... > File third_party/WebKit/Source/web/mac/WebSubstringUtil.mm (right): > > https://codereview.chromium.org/1616813002/diff/80001/third_party/WebKit/Sour... > third_party/WebKit/Source/web/mac/WebSubstringUtil.mm:116: IntRect stringRect = > frameView->contentsToRootFrame(createRange(range)->boundingBox()); > On 2016/01/29 at 05:57:59, Shu Chen wrote: > > On 2016/01/29 05:49:14, keishi wrote: > > > According to the comment boundingRect considers css transforms. Did you need > to > > > change it to boundingBox? > > > > If using boundingRect, the result is wrong for zoom'ed page. > > > > How can I verify wether boundingBox can work well with css transforms? > > Add CSS property "-webkit-transform", e.g. -webkit-transform: rotate(45deg) > https://developer.mozilla.org/en-US/docs/Web/CSS/transform Just tried, both boundingRect & boundingBox don't support the CSS transform (rotate example you made). I think changing it to boundingBox can fix the bug and won't cause regressions.
On 2016/01/29 at 09:05:49, shuchen wrote: > On 2016/01/29 06:30:53, Yosi_UTC9 wrote: > > https://codereview.chromium.org/1616813002/diff/80001/third_party/WebKit/Sour... > > File third_party/WebKit/Source/web/mac/WebSubstringUtil.mm (right): > > > > https://codereview.chromium.org/1616813002/diff/80001/third_party/WebKit/Sour... > > third_party/WebKit/Source/web/mac/WebSubstringUtil.mm:116: IntRect stringRect = > > frameView->contentsToRootFrame(createRange(range)->boundingBox()); > > On 2016/01/29 at 05:57:59, Shu Chen wrote: > > > On 2016/01/29 05:49:14, keishi wrote: > > > > According to the comment boundingRect considers css transforms. Did you need > > to > > > > change it to boundingBox? > > > > > > If using boundingRect, the result is wrong for zoom'ed page. > > > > > > How can I verify wether boundingBox can work well with css transforms? > > > > Add CSS property "-webkit-transform", e.g. -webkit-transform: rotate(45deg) > > https://developer.mozilla.org/en-US/docs/Web/CSS/transform > > Just tried, both boundingRect & boundingBox don't support the CSS transform (rotate example you made). > > I think changing it to boundingBox can fix the bug and won't cause regressions. How about using | LayoutObject::absoluteBoundingBoxRectForRange()|? It computes bounding box from quads. Thus, it consider CSS transform.
I've done my research and using boundingBox seems OK. (We should support CSS transform though) I've compiled a table comparing the coordinates in play here. https://docs.google.com/spreadsheets/d/1wxdjb1HXuhlSKt-ElGKElu1uelcPu6qUgqztY... Range::boundingBox seems to return CSS space coordinates. The baselinePoint returned from getBaselinePoint is being directly passed to [NSView showDefinitionForAttributedString:atPoint:]. It expects a point relative to the RenderViewHost NSView. (last row in table) Mac track pad pinch zoom uses "page-scale" to zoom instead of "page-zoom" https://code.google.com/p/chromium/issues/detail?id=451559 We need an non standard coordinate that applies page-scale zoom but the origin is the root frame. We should support page-scale zoom too but we can just leave a TODO comment for now.
On 2016/01/29 10:54:42, keishi wrote: > I've done my research and using boundingBox seems OK. (We should support CSS > transform though) > > I've compiled a table comparing the coordinates in play here. > https://docs.google.com/spreadsheets/d/1wxdjb1HXuhlSKt-ElGKElu1uelcPu6qUgqztY... > > Range::boundingBox seems to return CSS space coordinates. > > The baselinePoint returned from getBaselinePoint is being directly passed to > [NSView showDefinitionForAttributedString:atPoint:]. > It expects a point relative to the RenderViewHost NSView. (last row in table) > > Mac track pad pinch zoom uses "page-scale" to zoom instead of "page-zoom" > https://code.google.com/p/chromium/issues/detail?id=451559 > We need an non standard coordinate that applies page-scale zoom but the origin > is the root frame. > We should support page-scale zoom too but we can just leave a TODO comment for > now. Thanks for the research & the detailed elaboration. Do you have ideas of why the baseline point seems not correct in the below screenshot (Chromium compiled with this cl)? https://screenshot.googleplex.com/gygGb6S5Dnn
On 2016/01/29 11:45:11, Shu Chen wrote: > On 2016/01/29 10:54:42, keishi wrote: > > I've done my research and using boundingBox seems OK. (We should support CSS > > transform though) > > > > I've compiled a table comparing the coordinates in play here. > > > https://docs.google.com/spreadsheets/d/1wxdjb1HXuhlSKt-ElGKElu1uelcPu6qUgqztY... > > > > Range::boundingBox seems to return CSS space coordinates. > > > > The baselinePoint returned from getBaselinePoint is being directly passed to > > [NSView showDefinitionForAttributedString:atPoint:]. > > It expects a point relative to the RenderViewHost NSView. (last row in table) > > > > Mac track pad pinch zoom uses "page-scale" to zoom instead of "page-zoom" > > https://code.google.com/p/chromium/issues/detail?id=451559 > > We need an non standard coordinate that applies page-scale zoom but the origin > > is the root frame. > > We should support page-scale zoom too but we can just leave a TODO comment for > > now. > > Thanks for the research & the detailed elaboration. > > Do you have ideas of why the baseline point seems not correct in the below > screenshot (Chromium compiled with this cl)? > https://screenshot.googleplex.com/gygGb6S5Dnn Btw, the scaled text uses the css: -webkit-transform:scale(5,5).
On 2016/01/29 11:46:41, Shu Chen wrote: > On 2016/01/29 11:45:11, Shu Chen wrote: > > On 2016/01/29 10:54:42, keishi wrote: > > > I've done my research and using boundingBox seems OK. (We should support CSS > > > transform though) > > > > > > I've compiled a table comparing the coordinates in play here. > > > > > > https://docs.google.com/spreadsheets/d/1wxdjb1HXuhlSKt-ElGKElu1uelcPu6qUgqztY... > > > > > > Range::boundingBox seems to return CSS space coordinates. > > > > > > The baselinePoint returned from getBaselinePoint is being directly passed to > > > [NSView showDefinitionForAttributedString:atPoint:]. > > > It expects a point relative to the RenderViewHost NSView. (last row in > table) > > > > > > Mac track pad pinch zoom uses "page-scale" to zoom instead of "page-zoom" > > > https://code.google.com/p/chromium/issues/detail?id=451559 > > > We need an non standard coordinate that applies page-scale zoom but the > origin > > > is the root frame. > > > We should support page-scale zoom too but we can just leave a TODO comment > for > > > now. > > > > Thanks for the research & the detailed elaboration. > > > > Do you have ideas of why the baseline point seems not correct in the below > > screenshot (Chromium compiled with this cl)? > > https://screenshot.googleplex.com/gygGb6S5Dnn > > Btw, the scaled text uses the css: -webkit-transform:scale(5,5). Not sure. Maybe for the line below in LayoutText::absoluteQuadsForRange, you can pass UseTransforms instead of 0. 467: quads.append(localToAbsoluteQuad(FloatRect(r), 0, wasFixed));
On 2016/01/29 11:59:28, keishi wrote: > On 2016/01/29 11:46:41, Shu Chen wrote: > > On 2016/01/29 11:45:11, Shu Chen wrote: > > > On 2016/01/29 10:54:42, keishi wrote: > > > > I've done my research and using boundingBox seems OK. (We should support > CSS > > > > transform though) > > > > > > > > I've compiled a table comparing the coordinates in play here. > > > > > > > > > > https://docs.google.com/spreadsheets/d/1wxdjb1HXuhlSKt-ElGKElu1uelcPu6qUgqztY... > > > > > > > > Range::boundingBox seems to return CSS space coordinates. > > > > > > > > The baselinePoint returned from getBaselinePoint is being directly passed > to > > > > [NSView showDefinitionForAttributedString:atPoint:]. > > > > It expects a point relative to the RenderViewHost NSView. (last row in > > table) > > > > > > > > Mac track pad pinch zoom uses "page-scale" to zoom instead of "page-zoom" > > > > https://code.google.com/p/chromium/issues/detail?id=451559 > > > > We need an non standard coordinate that applies page-scale zoom but the > > origin > > > > is the root frame. > > > > We should support page-scale zoom too but we can just leave a TODO comment > > for > > > > now. > > > > > > Thanks for the research & the detailed elaboration. > > > > > > Do you have ideas of why the baseline point seems not correct in the below > > > screenshot (Chromium compiled with this cl)? > > > https://screenshot.googleplex.com/gygGb6S5Dnn > > > > Btw, the scaled text uses the css: -webkit-transform:scale(5,5). > > Not sure. Maybe for the line below in LayoutText::absoluteQuadsForRange, you can > pass UseTransforms instead of 0. > 467: quads.append(localToAbsoluteQuad(FloatRect(r), 0, wasFixed)); But if you do change that, we need to be careful because it changes the web exposed Range.getClientRects(). We would need to make sure accounting for CSS transforms is following the spec. (I think we should be considering CSS transforms.)
On 2016/01/29 12:04:40, keishi wrote: > On 2016/01/29 11:59:28, keishi wrote: > > On 2016/01/29 11:46:41, Shu Chen wrote: > > > On 2016/01/29 11:45:11, Shu Chen wrote: > > > > On 2016/01/29 10:54:42, keishi wrote: > > > > > I've done my research and using boundingBox seems OK. (We should support > > CSS > > > > > transform though) > > > > > > > > > > I've compiled a table comparing the coordinates in play here. > > > > > > > > > > > > > > > https://docs.google.com/spreadsheets/d/1wxdjb1HXuhlSKt-ElGKElu1uelcPu6qUgqztY... > > > > > > > > > > Range::boundingBox seems to return CSS space coordinates. > > > > > > > > > > The baselinePoint returned from getBaselinePoint is being directly > passed > > to > > > > > [NSView showDefinitionForAttributedString:atPoint:]. > > > > > It expects a point relative to the RenderViewHost NSView. (last row in > > > table) > > > > > > > > > > Mac track pad pinch zoom uses "page-scale" to zoom instead of > "page-zoom" > > > > > https://code.google.com/p/chromium/issues/detail?id=451559 > > > > > We need an non standard coordinate that applies page-scale zoom but the > > > origin > > > > > is the root frame. > > > > > We should support page-scale zoom too but we can just leave a TODO > comment > > > for > > > > > now. > > > > > > > > Thanks for the research & the detailed elaboration. > > > > > > > > Do you have ideas of why the baseline point seems not correct in the below > > > > screenshot (Chromium compiled with this cl)? > > > > https://screenshot.googleplex.com/gygGb6S5Dnn > > > > > > Btw, the scaled text uses the css: -webkit-transform:scale(5,5). > > > > Not sure. Maybe for the line below in LayoutText::absoluteQuadsForRange, you > can > > pass UseTransforms instead of 0. > > 467: quads.append(localToAbsoluteQuad(FloatRect(r), 0, wasFixed)); > > But if you do change that, we need to be careful because it changes the web > exposed Range.getClientRects(). We would need to make sure accounting for CSS > transforms is following the spec. (I think we should be considering CSS > transforms.) Just confirmed that Range::boundingBox does support the CSS transforms. The problem in https://screenshot.googleplex.com/gygGb6S5Dnn is caused by the incorrect *font* carried by NSAttributedString. It may be possible to support "translate" & "scale(x,x)", but it seems impossible to support "rotate" & "scale(x,y)". Anyway, the full support for correct Font according to CSS transform can be a separated cl. Let's remain this cl as small as possible for better merge to M49. yosin@/keishi@, does that sounds good to you?
On 2016/01/31 02:25:08, Shu Chen wrote: > On 2016/01/29 12:04:40, keishi wrote: > > On 2016/01/29 11:59:28, keishi wrote: > > > On 2016/01/29 11:46:41, Shu Chen wrote: > > > > On 2016/01/29 11:45:11, Shu Chen wrote: > > > > > On 2016/01/29 10:54:42, keishi wrote: > > > > > > I've done my research and using boundingBox seems OK. (We should > support > > > CSS > > > > > > transform though) > > > > > > > > > > > > I've compiled a table comparing the coordinates in play here. > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/spreadsheets/d/1wxdjb1HXuhlSKt-ElGKElu1uelcPu6qUgqztY... > > > > > > > > > > > > Range::boundingBox seems to return CSS space coordinates. > > > > > > > > > > > > The baselinePoint returned from getBaselinePoint is being directly > > passed > > > to > > > > > > [NSView showDefinitionForAttributedString:atPoint:]. > > > > > > It expects a point relative to the RenderViewHost NSView. (last row in > > > > table) > > > > > > > > > > > > Mac track pad pinch zoom uses "page-scale" to zoom instead of > > "page-zoom" > > > > > > https://code.google.com/p/chromium/issues/detail?id=451559 > > > > > > We need an non standard coordinate that applies page-scale zoom but > the > > > > origin > > > > > > is the root frame. > > > > > > We should support page-scale zoom too but we can just leave a TODO > > comment > > > > for > > > > > > now. > > > > > > > > > > Thanks for the research & the detailed elaboration. > > > > > > > > > > Do you have ideas of why the baseline point seems not correct in the > below > > > > > screenshot (Chromium compiled with this cl)? > > > > > https://screenshot.googleplex.com/gygGb6S5Dnn > > > > > > > > Btw, the scaled text uses the css: -webkit-transform:scale(5,5). > > > > > > Not sure. Maybe for the line below in LayoutText::absoluteQuadsForRange, you > > can > > > pass UseTransforms instead of 0. > > > 467: quads.append(localToAbsoluteQuad(FloatRect(r), 0, wasFixed)); > > > > But if you do change that, we need to be careful because it changes the web > > exposed Range.getClientRects(). We would need to make sure accounting for CSS > > transforms is following the spec. (I think we should be considering CSS > > transforms.) > > Just confirmed that Range::boundingBox does support the CSS transforms. > > The problem in https://screenshot.googleplex.com/gygGb6S5Dnn is caused by the > incorrect *font* carried by NSAttributedString. > It may be possible to support "translate" & "scale(x,x)", but it seems > impossible to support "rotate" & "scale(x,y)". > Anyway, the full support for correct Font according to CSS transform can be a > separated cl. > Let's remain this cl as small as possible for better merge to M49. > > yosin@/keishi@, does that sounds good to you? LGTM Just supporting translate and scale is the best we can do. Please add TODO about the missing CSS transform and page-zoom support.
On 2016/01/31 03:56:35, keishi wrote: > On 2016/01/31 02:25:08, Shu Chen wrote: > > On 2016/01/29 12:04:40, keishi wrote: > > > On 2016/01/29 11:59:28, keishi wrote: > > > > On 2016/01/29 11:46:41, Shu Chen wrote: > > > > > On 2016/01/29 11:45:11, Shu Chen wrote: > > > > > > On 2016/01/29 10:54:42, keishi wrote: > > > > > > > I've done my research and using boundingBox seems OK. (We should > > support > > > > CSS > > > > > > > transform though) > > > > > > > > > > > > > > I've compiled a table comparing the coordinates in play here. > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/spreadsheets/d/1wxdjb1HXuhlSKt-ElGKElu1uelcPu6qUgqztY... > > > > > > > > > > > > > > Range::boundingBox seems to return CSS space coordinates. > > > > > > > > > > > > > > The baselinePoint returned from getBaselinePoint is being directly > > > passed > > > > to > > > > > > > [NSView showDefinitionForAttributedString:atPoint:]. > > > > > > > It expects a point relative to the RenderViewHost NSView. (last row > in > > > > > table) > > > > > > > > > > > > > > Mac track pad pinch zoom uses "page-scale" to zoom instead of > > > "page-zoom" > > > > > > > https://code.google.com/p/chromium/issues/detail?id=451559 > > > > > > > We need an non standard coordinate that applies page-scale zoom but > > the > > > > > origin > > > > > > > is the root frame. > > > > > > > We should support page-scale zoom too but we can just leave a TODO > > > comment > > > > > for > > > > > > > now. > > > > > > > > > > > > Thanks for the research & the detailed elaboration. > > > > > > > > > > > > Do you have ideas of why the baseline point seems not correct in the > > below > > > > > > screenshot (Chromium compiled with this cl)? > > > > > > https://screenshot.googleplex.com/gygGb6S5Dnn > > > > > > > > > > Btw, the scaled text uses the css: -webkit-transform:scale(5,5). > > > > > > > > Not sure. Maybe for the line below in LayoutText::absoluteQuadsForRange, > you > > > can > > > > pass UseTransforms instead of 0. > > > > 467: quads.append(localToAbsoluteQuad(FloatRect(r), 0, wasFixed)); > > > > > > But if you do change that, we need to be careful because it changes the web > > > exposed Range.getClientRects(). We would need to make sure accounting for > CSS > > > transforms is following the spec. (I think we should be considering CSS > > > transforms.) > > > > Just confirmed that Range::boundingBox does support the CSS transforms. > > > > The problem in https://screenshot.googleplex.com/gygGb6S5Dnn is caused by the > > incorrect *font* carried by NSAttributedString. > > It may be possible to support "translate" & "scale(x,x)", but it seems > > impossible to support "rotate" & "scale(x,y)". > > Anyway, the full support for correct Font according to CSS transform can be a > > separated cl. > > Let's remain this cl as small as possible for better merge to M49. > > > > yosin@/keishi@, does that sounds good to you? > > LGTM > Just supporting translate and scale is the best we can do. Please add TODO about > the missing CSS transform and page-zoom support. Done. I've added 2 TODOs.
LGTM
The CQ bit was checked by shuchen@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1616813002/100001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1616813002/100001
Message was sent while issue was closed.
Description was changed from ========== Consider Zoom factor when getting bounding rect. BUG=579007 ========== to ========== Consider Zoom factor when getting bounding rect. BUG=579007 ==========
Message was sent while issue was closed.
Committed patchset #6 (id:100001)
Message was sent while issue was closed.
Description was changed from ========== Consider Zoom factor when getting bounding rect. BUG=579007 ========== to ========== Consider Zoom factor when getting bounding rect. BUG=579007 Committed: https://crrev.com/126e210435ab183a1cb2000b78379cf71aac94fd Cr-Commit-Position: refs/heads/master@{#372588} ==========
Message was sent while issue was closed.
Patchset 6 (id:??) landed as https://crrev.com/126e210435ab183a1cb2000b78379cf71aac94fd Cr-Commit-Position: refs/heads/master@{#372588} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
