RESOLVED FIXED 91231
FormController, WebHistoryItem: Enable reading selected file names from document state
https://bugs.webkit.org/show_bug.cgi?id=91231
Summary FormController, WebHistoryItem: Enable reading selected file names from docum...
Marja Hölttä
Reported 2012-07-13 06:27:35 PDT
Chromium would need to read the selected file names from the document state, in order to set the file permissions properly after restoring a page which contains a form with selected files. The patch I'll soon add adds WebDocumentState which has a function for getting the file names. Migration plan: Patch 1, webkit: WebDocumentState WebHistoryItem::documentState(bool) << added WebVector<WebString> WebHistoryItem::documentState() << old one Patch 2, chromium: use documentState(true) Patch 3, webkit: WebDocumentState WebHistoryItem::documentState(bool = true) Patch 4: chromium: use documentState() Patch 5, webkit: WebDocumentState WebHistoryItem::documentState()
Attachments
. (8.23 KB, patch)
2012-07-13 06:37 PDT, Marja Hölttä
no flags
Patch (3.27 KB, patch)
2012-08-07 06:05 PDT, Marja Hölttä
no flags
Patch (9.67 KB, patch)
2012-08-09 02:11 PDT, Marja Hölttä
no flags
Patch (9.89 KB, patch)
2012-08-09 05:29 PDT, Marja Hölttä
no flags
Patch (14.37 KB, patch)
2012-08-14 01:13 PDT, Marja Hölttä
no flags
Patch (14.32 KB, patch)
2012-08-14 02:31 PDT, Marja Hölttä
no flags
Patch (21.56 KB, patch)
2012-08-14 05:07 PDT, Marja Hölttä
no flags
Patch (25.92 KB, patch)
2012-08-14 06:52 PDT, Marja Hölttä
no flags
Patch (26.00 KB, patch)
2012-08-14 08:07 PDT, Marja Hölttä
no flags
Patch (25.95 KB, patch)
2012-08-16 01:14 PDT, Marja Hölttä
no flags
Marja Hölttä
Comment 1 2012-07-13 06:37:24 PDT
WebKit Review Bot
Comment 2 2012-07-13 06:42:19 PDT
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
jochen
Comment 3 2012-07-13 06:49:53 PDT
Comment on attachment 152246 [details] . Can you add a test that this works? See tests/WebViewTest for how to easily create a HTMLDocument Also, a ChangeLog is missing :) View in context: https://bugs.webkit.org/attachment.cgi?id=152246&action=review > Source/WebKit/chromium/public/WebDocumentState.h:39 > + WebDocumentState(const WebVector<WebString>&); explicit? > Source/WebKit/chromium/public/WebHistoryItem.h:106 > WEBKIT_EXPORT WebVector<WebString> documentState() const; I'd group the new and old methods together and add a // FIXME: comment about removing the old ones and dropping the bool > Source/WebKit/chromium/src/WebDocumentState.cpp:37 > + : m_data(documentState) the constructor and the data() accessor are so small, you could move them to the header > Source/WebKit/chromium/src/WebHistoryItem.cpp:221 > +void WebHistoryItem::setDocumentState(const WebDocumentState& state) can you implement the old setDocumentState / documentState by means of the new methods, so we don't have a copy of the code?
WebKit Review Bot
Comment 4 2012-07-13 07:45:26 PDT
Comment on attachment 152246 [details] . Attachment 152246 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13237129
Darin Fisher (:fishd, Google)
Comment 5 2012-07-13 09:53:33 PDT
Comment on attachment 152246 [details] . Is exposing a WebDocumentState primitive really the best thing to do? I've always found the concept of "document state" rather vague / cryptic. Maybe it just needs a better name, or maybe the functionality that you really need could / should just be a method on WebHistoryItem?
jochen
Comment 6 2012-07-13 12:10:33 PDT
(In reply to comment #5) > (From update of attachment 152246 [details]) > Is exposing a WebDocumentState primitive really the best thing to do? I've always > found the concept of "document state" rather vague / cryptic. Maybe it just needs > a better name, or maybe the functionality that you really need could / should just > be a method on WebHistoryItem? The intention is to allow access to the files for the file input elements restored from the document state (see https://chromiumcodereview.appspot.com/10695107/) without deserializing the document state in webkit/glue
Darin Fisher (:fishd, Google)
Comment 7 2012-07-13 13:23:03 PDT
(In reply to comment #6) > (In reply to comment #5) > > (From update of attachment 152246 [details] [details]) > > Is exposing a WebDocumentState primitive really the best thing to do? I've always > > found the concept of "document state" rather vague / cryptic. Maybe it just needs > > a better name, or maybe the functionality that you really need could / should just > > be a method on WebHistoryItem? > > The intention is to allow access to the files for the file input elements restored from the document state (see https://chromiumcodereview.appspot.com/10695107/) without deserializing the document state in webkit/glue WebHistoryItem::getReferencedFilePaths?
jochen
Comment 8 2012-07-13 13:26:32 PDT
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > (From update of attachment 152246 [details] [details] [details]) > > > Is exposing a WebDocumentState primitive really the best thing to do? I've always > > > found the concept of "document state" rather vague / cryptic. Maybe it just needs > > > a better name, or maybe the functionality that you really need could / should just > > > be a method on WebHistoryItem? > > > > The intention is to allow access to the files for the file input elements restored from the document state (see https://chromiumcodereview.appspot.com/10695107/) without deserializing the document state in webkit/glue > > WebHistoryItem::getReferencedFilePaths? sg
Marja Hölttä
Comment 9 2012-08-07 06:05:50 PDT
jochen
Comment 10 2012-08-07 06:26:07 PDT
ok, since it touches the WebKit API, we'll need to wait for Darin
Marja Hölttä
Comment 11 2012-08-09 02:11:17 PDT
jochen
Comment 12 2012-08-09 05:13:37 PDT
Comment on attachment 157429 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=157429&action=review > Tools/DumpRenderTree/chromium/LayoutTestController.cpp:2355 > + result->setNull(); why not ->set("") ? > Tools/DumpRenderTree/chromium/LayoutTestController.cpp:2356 > + WebHistoryItem historyItem = m_shell->webViewHost()->webView()->focusedFrame()->currentHistoryItem(); m_shell->webView() should be enough > LayoutTests/platform/chromium/fast/forms/file/selected-files-from-history-state.html:13 > + testFailed('This test requires a LayoutTestController.'); it's called TestRunner these days > LayoutTests/platform/chromium/fast/forms/file/selected-files-from-history-state.html:43 > +<p id="description"></p> please add a short description what the test is supposed to do
Marja Hölttä
Comment 13 2012-08-09 05:29:42 PDT
Marja Hölttä
Comment 14 2012-08-09 05:30:31 PDT
Thanks for comments, the new patch addresses all of them.
jochen
Comment 15 2012-08-09 05:31:07 PDT
(In reply to comment #14) > Thanks for comments, the new patch addresses all of them. Thanks Darin, are the WebKit API changes ok?
Darin Fisher (:fishd, Google)
Comment 16 2012-08-09 11:09:14 PDT
Comment on attachment 157448 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=157448&action=review > Source/WebKit/chromium/src/WebHistoryItem.cpp:290 > +WebVector<WebString> WebHistoryItem::getReferredFilePaths() const nit: getReferencedFilePaths(). getReferredFilePaths() sounds a bit awkward to me. did you have a reason for preferring "referred" here? just because it is shorter? > Source/WebKit/chromium/src/WebHistoryItem.cpp:292 > + WTF::Vector<WebString> filePaths; nit: no need for WTF:: in .cpp files > Source/WebKit/chromium/src/WebHistoryItem.cpp:295 > + WebHTTPBody::Element element; nit: prefer using WebCore types inside the implementation of WebKit. There are hidden costs to using WebKit API here. > Source/WebKit/chromium/src/WebHistoryItem.cpp:302 > + const WebVector<WebString>& state = documentState(); it is a bit wasteful to allocate a WebVector here. you should just use Vector<String> as returned by m_private->documentState() to avoid copying the array. > Source/WebKit/chromium/src/WebHistoryItem.cpp:304 > + while (i + 2 < state.size()) { you should explain what these magic numbers are all about. > Source/WebKit/chromium/src/WebHistoryItem.cpp:317 > + WebVector<WebString> toReturn(filePaths.size()); nit: you can just do "return filePaths;" and it will automagically create a WebVector<WebString> for you. > Tools/DumpRenderTree/chromium/LayoutTestController.cpp:2353 > +void LayoutTestController::getReferredFiles(const CppArgumentList& arguments, CppVariant* result) can you do this by extending Internals.idl instead? we try to avoid adding new methods on LayoutTestController (now TestRunner) when possible.
Kent Tamura
Comment 17 2012-08-09 16:59:33 PDT
Comment on attachment 157448 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=157448&action=review > Source/WebKit/chromium/src/WebHistoryItem.cpp:316 > + const WebVector<WebString>& state = documentState(); > + size_t i = 3; > + while (i + 2 < state.size()) { > + bool ok = false; > + size_t fields = WTF::String(state[i + 2]).toInt(&ok); > + if (!ok) > + break; > + if (i + 2 + fields >= state.size()) > + break; > + if (state[i + 1] == "file") { > + for (size_t j = i + 3; j < i + 3 + fields; j += 2) > + filePaths.append(state[j]); > + } > + i += (3 + fields); > + } This is not a good idea. The internal structure of documentState() is not exposed from WebCore and it is changeable. Actually, this code is for an old version of the structure and it doesn't work now. I recommend to add a function to WebCore/html/FormController.{cpp,h}. The function deserializes SavedFormState objects from the documentState vector, collects the file paths in SavedFormState, and returns them.
Marja Hölttä
Comment 18 2012-08-14 01:13:05 PDT
Marja Hölttä
Comment 19 2012-08-14 01:14:47 PDT
Comment on attachment 157448 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=157448&action=review >> Source/WebKit/chromium/src/WebHistoryItem.cpp:290 >> +WebVector<WebString> WebHistoryItem::getReferredFilePaths() const > > nit: getReferencedFilePaths(). getReferredFilePaths() sounds a bit awkward > to me. did you have a reason for preferring "referred" here? just because > it is shorter? Changed to getReferencedFilePaths. >> Source/WebKit/chromium/src/WebHistoryItem.cpp:292 >> + WTF::Vector<WebString> filePaths; > > nit: no need for WTF:: in .cpp files Done >> Source/WebKit/chromium/src/WebHistoryItem.cpp:295 >> + WebHTTPBody::Element element; > > nit: prefer using WebCore types inside the implementation of WebKit. > There are hidden costs to using WebKit API here. Done. >> Source/WebKit/chromium/src/WebHistoryItem.cpp:302 >> + const WebVector<WebString>& state = documentState(); > > it is a bit wasteful to allocate a WebVector here. you should just > use Vector<String> as returned by m_private->documentState() to avoid > copying the array. Done. >> Source/WebKit/chromium/src/WebHistoryItem.cpp:304 >> + while (i + 2 < state.size()) { > > you should explain what these magic numbers are all about. The code was moved to FormController / SavedFormState / FormControlState -> less magic numbers. >> Source/WebKit/chromium/src/WebHistoryItem.cpp:316 >> + } > > This is not a good idea. > The internal structure of documentState() is not exposed from WebCore and it is changeable. Actually, this code is for an old version of the structure and it doesn't work now. > > I recommend to add a function to WebCore/html/FormController.{cpp,h}. The function deserializes SavedFormState objects from the documentState vector, collects the file paths in SavedFormState, and returns them. Moved the logic to FormController / SavedFormState / FormControlState. (The serialization format has changed recently but afaics this uses the new version.) >> Source/WebKit/chromium/src/WebHistoryItem.cpp:317 >> + WebVector<WebString> toReturn(filePaths.size()); > > nit: you can just do "return filePaths;" and it will automagically > create a WebVector<WebString> for you. Done >> Tools/DumpRenderTree/chromium/LayoutTestController.cpp:2353 >> +void LayoutTestController::getReferredFiles(const CppArgumentList& arguments, CppVariant* result) > > can you do this by extending Internals.idl instead? we try to avoid adding new methods > on LayoutTestController (now TestRunner) when possible. Done
jochen
Comment 20 2012-08-14 01:47:31 PDT
Comment on attachment 158251 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=158251&action=review > Source/WebCore/ChangeLog:18 > + (WebCore::FormController::getReferencedFilePaths): please add a comment to the newly added methods explaining what they do > Source/WebCore/html/FormController.cpp:81 > + for (size_t i = 0; i < m_values.size(); i += 2) { this seems to assume that the FormControlState is representing a file input which is not necessarily true. I think I'd prefer a static function that does the magic of getting the filepaths out of the form control state. It could be something like getReferencedFilePathsForFileFormControlState(FormControlState&) or so > Source/WebCore/html/FormController.cpp:287 > + const Vector<String>& files = queIterator->getReferencedFilePaths(); just toReturn.append(queIterator->getReferencedFilePaths()) > Source/WebCore/html/FormController.cpp:522 > + const Vector<String>& filePaths = state->getReferencedFilePaths(); just toReturn.append(state->getReferencedFilePaths()) > Source/WebCore/testing/Internals.cpp:1198 > + for (size_t i = 0; i < filePaths.size(); ++i) you could Vector<String>& result = stringList; result.append(filePaths)
jochen
Comment 21 2012-08-14 01:51:18 PDT
You should probably also update the bug title now that it's not a WebHistoryItem-only change anymore
Marja Hölttä
Comment 22 2012-08-14 02:31:24 PDT
Kent Tamura
Comment 23 2012-08-14 02:32:48 PDT
Comment on attachment 158251 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=158251&action=review > Source/WebCore/html/FormController.cpp:84 > +Vector<String> FormControlState::getReferencedFilePaths() const > +{ > + Vector<String> toReturn; > + for (size_t i = 0; i < m_values.size(); i += 2) { > + if (!m_values[i].isNull()) > + toReturn.append(m_values[i]); > + } This logic should be in FileInputType.cpp because of encapsulation. > Source/WebCore/html/FormController.cpp:521 > +Vector<String> FormController::getReferencedFilePaths(const Vector<String>& stateVector) > +{ > + Vector<String> toReturn; > + size_t i = 0; > + if (stateVector.size() < 1 || stateVector[i++] != formStateSignature()) > + return toReturn; > + while (i + 1 < stateVector.size()) { > + ++i; // Skip form key. > + OwnPtr<SavedFormState> state = SavedFormState::deserialize(stateVector, i); > + if (!state) > + break; We should share the code with FormController::setStateForNewFormElements().
Build Bot
Comment 24 2012-08-14 03:27:26 PDT
Build Bot
Comment 25 2012-08-14 04:48:54 PDT
Marja Hölttä
Comment 26 2012-08-14 05:07:55 PDT
Marja Hölttä
Comment 27 2012-08-14 05:10:43 PDT
Comment on attachment 158251 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=158251&action=review >> Source/WebCore/ChangeLog:18 >> + (WebCore::FormController::getReferencedFilePaths): > > please add a comment to the newly added methods explaining what they do Done >> Source/WebCore/html/FormController.cpp:81 >> + for (size_t i = 0; i < m_values.size(); i += 2) { > > this seems to assume that the FormControlState is representing a file input which is not necessarily true. I think I'd prefer a static function that does the magic of getting the filepaths out of the form control state. It could be something like getReferencedFilePathsForFileFormControlState(FormControlState&) or so The logic is moved to FileInputType.cpp >> Source/WebCore/html/FormController.cpp:84 >> + } > > This logic should be in FileInputType.cpp because of encapsulation. Done >> Source/WebCore/html/FormController.cpp:521 >> + break; > > We should share the code with FormController::setStateForNewFormElements(). Done
Build Bot
Comment 28 2012-08-14 06:16:19 PDT
Marja Hölttä
Comment 29 2012-08-14 06:52:32 PDT
jochen
Comment 30 2012-08-14 07:29:46 PDT
Comment on attachment 158316 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=158316&action=review > Source/WebCore/ChangeLog:8 > + Additional information of the change such as approach, rationale. Please add per-function descriptions below (OOPS!). You forgot to copy this over from the last version > ChangeLog:8 > + Additional information of the change such as approach, rationale. Please add per-function descriptions below (OOPS!). same here
Marja Hölttä
Comment 31 2012-08-14 08:07:24 PDT
Marja Hölttä
Comment 32 2012-08-14 08:08:26 PDT
Comment on attachment 158316 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=158316&action=review >> Source/WebCore/ChangeLog:8 >> + Additional information of the change such as approach, rationale. Please add per-function descriptions below (OOPS!). > > You forgot to copy this over from the last version Fixed >> ChangeLog:8 >> + Additional information of the change such as approach, rationale. Please add per-function descriptions below (OOPS!). > > same here Fixed
jochen
Comment 33 2012-08-14 08:33:33 PDT
Comment on attachment 158333 [details] Patch let's wait for darin or tkent before cq
Kent Tamura
Comment 34 2012-08-14 18:22:02 PDT
Comment on attachment 158333 [details] Patch Looks ok.
WebKit Review Bot
Comment 35 2012-08-16 00:56:04 PDT
Comment on attachment 158333 [details] Patch Rejecting attachment 158333 [details] from commit-queue. Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2 Last 500 characters of output: ucceeded at 71 (offset 1 line). patching file LayoutTests/ChangeLog Hunk #1 succeeded at 1 with fuzz 3. patching file LayoutTests/fast/forms/file/selected-files-from-history-state-expected.txt patching file LayoutTests/fast/forms/file/selected-files-from-history-state.html patching file ChangeLog Hunk #1 succeeded at 1 with fuzz 3. Failed to run "[u'/mnt/git/webkit-commit-queue/Tools/Scripts/svn-apply', u'--force', u'--reviewer', u'Jochen Eis..." exit_code: 1 cwd: /mnt/git/webkit-commit-queue/ Full output: http://queues.webkit.org/results/13509508
Marja Hölttä
Comment 36 2012-08-16 01:14:45 PDT
WebKit Review Bot
Comment 37 2012-08-16 01:52:41 PDT
Comment on attachment 158744 [details] Patch Clearing flags on attachment: 158744 Committed r125759: <http://trac.webkit.org/changeset/125759>
WebKit Review Bot
Comment 38 2012-08-16 01:52:49 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.