Issue metadata
Sign in to add a comment
|
"Search Google for" text in right click context menu has poor Unicode support
Reported by
aja...@gmail.com,
Sep 30 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36 Steps to reproduce the problem: 1. Select and right-click both of the following groups of text: πππππππππππππππ π‘π’π£π€π₯π¦π§π¨π©πͺπ« πΈπΉβπ»πΌπ½πΎβπππππβπβββπππππππβ€ 2. Note the boxes in place of Unicode letters. The characters that render correctly (at least on my end, βββββββ€ if you're seeing something different) are the ones which UTF-16 represents as a single code unit. Whether this is correlation or causation I do not know. 3. If you have an extension installed with a similar context-menu selected-text display (find one for testing here: https://chrome.google.com/webstore/search/search%20right%20click?_category=ext/7-productivity), note that it *does* correctly render the selected text. 4. You'll probably also note that in both cases the text in the first group appears to be abbreviated halfway through a surrogate pair, but that's a seperate issue. What is the expected behavior? The "Search Google for" context menu item should be able to correctly render any character that the rest of Chrome can, and especially any character that an extension can correctly render just below it. What went wrong? The "Search Google for" context menu item displays "unknown character" boxes in place of characters that other parts of the context menu can successfully render. Did this work before? No Chrome version: 53.0.2785.143 Channel: n/a OS Version: 8.1 Flash Version: Shockwave Flash 23.0 r0 Attached are some screenshots of what I see, in case of trouble reproducing it. The extension is one I made for personal use; it just uses the built-in %s replacer, as described on https://developer.chrome.com/extensions/contextMenus .
,
Oct 3 2016
Able to reproduce the issue on windows 7 using chrome version 53.0.2785.143 and canary 55.0.2878.0 with the below steps 1.Open https://bugs.chromium.org/p/chromium/issues/detail?id=651948 2.select and right click on text "πΈπΉβπ»πΌπ½πΎβπππππβπβββπππππππβ€" mentioned in step 1 of comment #0 3.Observe the boxes in context menu This is reproducible on windows only and it is regression issue broken in M48.Please find the bisect information as below Narrow Bisect:: ============== Good :: 48.0.2544.0 -- (build revision 355679) Bad:: 48.0.2545.0 -- (build revision 355918) CHANGELOG URL:: ============ https://chromium.googlesource.com/chromium/src/+log/9ddcbe9c869061a9a76aecd65b842849aa1fca16..0b58cf7fcc5c2d1608992f374d327ce9a023b0a2 Possible suspect from the above CL https://chromium.googlesource.com/chromium/src/+/69cab515d4cbf5445dbf4ba96bc168c54d0aac8c drott@ could you please look into this issue if it is related to your change,else please route this to an appropriate owner for this issue. Thanks,
,
Oct 3 2016
The identified commit is not the core problem. Without this change in HarfBuzz, HarfBuzz was more aggressively trying to find characters "as close as", but not identical to the original characters in the text, which is practically hiding the fact that the UI font code does not identify a correct fallback font in this case. For example, if the font had an "A" glyph, it was showing that for a "πΈ". However we don't want that behavior in HarfBuzz as it's not accurately representing the original text. The right solution here is better fallback for the characters in question.
,
Oct 3 2016
,
Nov 17 2016
Able to reproduce this issue on windows 7 with latest chrome version 54.0.2840.99 Can anyone from dev team will look into this issue. Note: ----- This issue is not reproducible in Windows 10.
,
Nov 17 2016
,
Nov 25 2016
Able to reproduce this issue on windows 7 with latest chrome canary 57.0.2931.0 Can anyone from dev team will look into this issue. Note: ----- This issue is not reproducible in Windows 10.
,
Dec 5 2016
Able to reproduce this issue on windows 7 with latest chrome canary 57.0.2939.0 Can anyone from dev team will look into this issue. Note: ----- This issue is not reproducible in Windows 10.
,
Dec 11 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 13
Archiving old bugs that haven't been actively assigned in over 180 days. If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ligim...@chromium.org
, Sep 30 2016