WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Patch
(3.27 KB, patch)
2012-08-07 06:05 PDT
,
Marja Hölttä
no flags
Details
Formatted Diff
Diff
Patch
(9.67 KB, patch)
2012-08-09 02:11 PDT
,
Marja Hölttä
no flags
Details
Formatted Diff
Diff
Patch
(9.89 KB, patch)
2012-08-09 05:29 PDT
,
Marja Hölttä
no flags
Details
Formatted Diff
Diff
Patch
(14.37 KB, patch)
2012-08-14 01:13 PDT
,
Marja Hölttä
no flags
Details
Formatted Diff
Diff
Patch
(14.32 KB, patch)
2012-08-14 02:31 PDT
,
Marja Hölttä
no flags
Details
Formatted Diff
Diff
Patch
(21.56 KB, patch)
2012-08-14 05:07 PDT
,
Marja Hölttä
no flags
Details
Formatted Diff
Diff
Patch
(25.92 KB, patch)
2012-08-14 06:52 PDT
,
Marja Hölttä
no flags
Details
Formatted Diff
Diff
Patch
(26.00 KB, patch)
2012-08-14 08:07 PDT
,
Marja Hölttä
no flags
Details
Formatted Diff
Diff
Patch
(25.95 KB, patch)
2012-08-16 01:14 PDT
,
Marja Hölttä
no flags
Details
Formatted Diff
Diff
Show Obsolete
(9)
View All
Add attachment
proposed patch, testcase, etc.
Marja Hölttä
Comment 1
2012-07-13 06:37:24 PDT
Created
attachment 152246
[details]
.
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
Created
attachment 156925
[details]
Patch
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
Created
attachment 157429
[details]
Patch
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
Created
attachment 157448
[details]
Patch
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
Created
attachment 158251
[details]
Patch
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
Created
attachment 158268
[details]
Patch
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
Comment on
attachment 158268
[details]
Patch
Attachment 158268
[details]
did not pass win-ews (win): Output:
http://queues.webkit.org/results/13504109
Build Bot
Comment 25
2012-08-14 04:48:54 PDT
Comment on
attachment 158268
[details]
Patch
Attachment 158268
[details]
did not pass mac-ews (mac): Output:
http://queues.webkit.org/results/13490533
Marja Hölttä
Comment 26
2012-08-14 05:07:55 PDT
Created
attachment 158299
[details]
Patch
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
Comment on
attachment 158299
[details]
Patch
Attachment 158299
[details]
did not pass win-ews (win): Output:
http://queues.webkit.org/results/13502183
Marja Hölttä
Comment 29
2012-08-14 06:52:32 PDT
Created
attachment 158316
[details]
Patch
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
Created
attachment 158333
[details]
Patch
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
Created
attachment 158744
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug