Blank Braille characters encoded on URL hash
Categories
(Firefox :: Address Bar, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox76 | --- | unaffected |
| firefox77 | --- | wontfix |
| firefox78 | --- | wontfix |
People
(Reporter: epidemian, Unassigned)
Details
Attachments
(1 file)
|
44.35 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0
Steps to reproduce:
Visit https://demian.ferrei.ro/snake
It's a silly snake game that's rendered on the URL via Braille characters.
It works fine on Firefox 76 and Chrome (81), but started "rendering" incorrectly on Firefox 77, since it started encoding blank Braille characters (see screenshot). I don't know if this a regression, since it worked differently on a previous FF version, or an intended change.
Also, I know this is a very silly use-case for the URL, and I can understand that FF might stop supporting suck gimmick for security reasons. I'm reporting this mostly to ask if this is an intended change, or an unexpected regression. And, if it's the later, is there some way I could render these characters unencoded on the URL? (I've already tried using the search string or the pathname instead of the hash, but it's the same result)
Thanks for developing the best browser! :)
Actual results:
The game does not render "properly" because the blank Braille characters are encoded (see attached screenshot), thus making the game unplayable on the address bar.
Expected results:
I expected the Braille characters to be rendered unescaped.
Comment 1•5 years ago
|
||
Because this bug's Severity is normal and has not been changed, and this bug's priority is -- (none,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
Comment 2•5 years ago
•
|
||
Hi Demian,
Thank you for reporting this ticket.
I tested the provided URL on Windows 10 on the following Firefox versions:
-
78.0a1 (2020-05-15) (64-bit) Nightly: reproducible
-
77.0b6 (64-bit) Beta: reproducible
-
Release 76.0.1 (64-bit): not reproducible
-
76.0b8 (64-bit) Beta: not reproducible
I will mark this ticket as NEW and add it to the Core: Disability Access AP component in the hope that someone from their team can look into this.
Core: Disability Access AP team: if a regression range is needed, please let me know.
Thanks,
Virginia
| Reporter | ||
Comment 3•5 years ago
|
||
Thanks Virginia for taking the time to confirm this!
I don't know if the Disability Access API is very accurate for this "bug", but I don't expect there to be a component for recreational hacks on the address bar hehe.
It'd be nice to know if this was an intentional or an unintentional change, thus a regression. If it were the later, maybe I can take a look into the code and see if I can fix it back; but if it was intentional, then there'd be no point to that I guess.
Cheers!
Comment 4•5 years ago
|
||
This isn't a disability access APIs bug, since it relates to the way things are displayed in the address bar. It isn't actually related to accessibility at all; it's just a "creative" use of braille Unicode characters.
Comment 5•5 years ago
|
||
This was done on purpose as part of a security fix, and unfortunately if you test it in Chrome Canary, it is the same.
I'm sorry it broke your nice demo but I suspect it will be harder and harder to get consecutive empty spaces in browser urlbars (where by empty space I also mean characters looking like empty space).
| Reporter | ||
Comment 6•5 years ago
|
||
Oh, yeah, just tested in Chrome Canary and it's the same. I should probably had done that before opening this issue.
Thanks for the clear response Marco! It's a bummer for the game yeah, but I can understand it's probably important for a URL to not look indistinguishable from another one just by blank spaces. And it was of course a hack, so it was expected to break at some point (it never worked on Safari for example :)
Updated•5 years ago
|
Description
•