Bug 175778

Summary: Perform special handling for whitespace and control characters
Product: WebKit Reporter: Myles C. Maxfield <mmaxfield>
Component: TextAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: jidanni, mmaxfield, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=268971
Bug Depends on:    
Bug Blocks: 206208    
Attachments:
Description Flags
Inspect Element in Epiphany none

Myles C. Maxfield
Reported 2017-08-21 12:02:03 PDT
Currently, we treat these characters just like any other characters, which means we perform font selection, and possibly render the .notdef glyph. Instead, we should educate WebKit about these characters so that we don't need fonts for them (for performance) and to guarantee they won't render. A few options: U+200B ZERO WIDTH SPACE U+FEFF unicode bidi characters U+2060 WORD JOINER & more
Attachments
Inspect Element in Epiphany (38.21 KB, image/jpeg)
2018-01-02 09:49 PST, Dan Jacobson 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Myles C. Maxfield
Comment 1 2017-08-21 12:02:40 PDT
The fix for this would be platform-non-specific.
Radar WebKit Bug Importer
Comment 2 2017-08-21 12:03:05 PDT
<rdar://problem/33996276>
Dan Jacobson
Comment 3 2017-09-16 03:41:07 PDT
Please do not render U+FEFF ZERO WIDTH NO-BREAK SPACE $ /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/MiniBrowser https://wiki.openstreetmap.org/wiki/List_of_OSM-based_services It looks terrible!
Dan Jacobson
Comment 4 2017-09-16 03:49:38 PDT
See also Bug 175489. I'm worried people will complain to webmasters. They probably have never seen such usually invisible characters now suddenly showing up in all their browsing years.
Dan Jacobson
Comment 5 2017-09-16 03:52:59 PDT
This should be almost as high priority a bug as if the browser inserted U+002E FULL STOP where it was not supposed to be, e.g., turning 12345 into 123.45!
Dan Jacobson
Comment 6 2018-01-02 09:49:33 PST
Created attachment 330323 [details] Inspect Element in Epiphany
Myles C. Maxfield
Comment 7 2018-01-02 10:17:32 PST
This bug is about not rendering these special characters. Currently, we treat these characters the same way as any other character, so we will look up fonts that can render them, ask those fonts for glyphs for those characters, and render whatever the font gives us. Instead, we should have explicit code in WebKit that specifically checks for these code points and simply ignores them (so they have no glyph and no advance width).
Myles C. Maxfield
Comment 8 2023-09-14 06:27:04 PDT
*** Bug 185976 has been marked as a duplicate of this bug. ***
Myles C. Maxfield
Comment 9 2023-09-14 06:29:48 PDT
In https://bugs.webkit.org/show_bug.cgi?id=185976 I naively deleted most of the overwriteCodePoint() calls inside createAndFillGlyphPage(). Simply deleting those is probably incomplete; what we probably should be doing is having deliberate handling for these characters, rather than swapping the characters with other characters and treating them normally (performing fallback, etc.)
Note You need to log in before you can comment on or make changes to this bug.