WebSQL openDatabase doesn't accept unicode characters
Reported by
rui.gar...@outsystems.com,
Jan 12 2017
|
|||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Steps to reproduce the problem:
1. Open Dev Tools;
2. Run window.openDatabase("日", "1.0", "Description!", 5 * 1024 * 1024);
What is the expected behavior?
Database is created, and the openDatabase returns the Db object without throwing errors.
What went wrong?
Even though the database is created. We can see that in with SQLLite studio, that call fails in runtime with what appears to be a silly bug reaching the file system. According to its spec, user agents should allow any db name. Quoting: "All strings including the empty string are valid database names. Database names must be compared in a case-sensitive manner. Note: Implementations can support this even in environments that only support a subset of all strings as database names by mapping database names (e.g. using a hashing algorithm) to the supported set of names." from: https://www.w3.org/TR/webdatabase/
Did this work before? No
Does this work in other browsers? N/A
Chrome version: 55.0.2883.87 Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 24.0 r0
,
Jan 12 2017
What is the behavior in Safari? Creating the database but then failing should probably be fixed. But if we have the same behavior as Safari in terms of valid names then we should probably leave that alone. (It'd be a bug against the spec to match implementations, but that will probably never happen.)
,
Jan 12 2017
My main machine is OSX, so I can check it out. I think the name is transformed on the way to the filesystem, so I'd expect it to work for arbitrary JS strings.
,
Jan 13 2017
Safari works fine. https://codereview.chromium.org/2634473002/ out for review.
,
Jan 13 2017
,
Jan 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/713773b46f90f18b194cd10c68a8f9ebacb2e49f commit 713773b46f90f18b194cd10c68a8f9ebacb2e49f Author: shess <shess@chromium.org> Date: Wed Jan 18 19:16:45 2017 [websql] Filenames are utf-8, not latin1. From WTFString.h: // Construct a string with latin1 data, from a null-terminated source. String(const char* characters); This is ... not right for this case. Why do we even HAVE that lever? String::fromUTF8() works better. Bug was basically that the above-SQLite code in the webdatabase module converted filenames differently from the below-SQLite code in chromium_vfs, so the above-level code caused the tracker to create things, but the below-level code couldn't find the matching record. BUG= 680410 R=jsbell@chromium.org TBR=michaeln@chromium.org Review-Url: https://codereview.chromium.org/2634473002 Cr-Commit-Position: refs/heads/master@{#444435} [add] https://crrev.com/713773b46f90f18b194cd10c68a8f9ebacb2e49f/third_party/WebKit/LayoutTests/storage/websql/open-database-utf8-name-expected.txt [add] https://crrev.com/713773b46f90f18b194cd10c68a8f9ebacb2e49f/third_party/WebKit/LayoutTests/storage/websql/open-database-utf8-name.html [modify] https://crrev.com/713773b46f90f18b194cd10c68a8f9ebacb2e49f/third_party/WebKit/Source/modules/webdatabase/sqlite/SQLiteFileSystemPosix.cpp [modify] https://crrev.com/713773b46f90f18b194cd10c68a8f9ebacb2e49f/third_party/WebKit/Source/modules/webdatabase/sqlite/SQLiteFileSystemWin.cpp
,
Jan 19 2017
With attached websql.html file, previously there was an exception: > unable to open database (14 unable to open database file) > (anonymous) @ websql.html:9 and pressing [bdb results] gave an alert. Pressing [adb] gave no results, because the exception prevented populating it and I'm too lazy to fix that. With the new version and some future canary, each button will give different results in the page.
,
Feb 14 2017
Verified on canary. OP, feel free to email me shess@chromium.org if you find that it is not fixed. [Looks like it landed at 57.0.2986.0, so I guess current beta channel should have it.] |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by tkent@chromium.org
, Jan 12 2017