| Summary: | hidden attribute on <input type=file /> suppresses the file selection dialog | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Darth <priyajeet.hora> | ||||||
| Component: | Forms | Assignee: | Rakesh <rakeshchaitan> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | abarth, ap, chuck, jrb473, priyajeet.hora, rakeshchaitan, rniwa, tkent, webkit.review.bot | ||||||
| Priority: | P2 | ||||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Attachments: |
|
||||||||
|
Description
Darth
2011-04-10 12:39:24 PDT
As per my observation, in Firefox and IE, we are able to open file system though the "file" element is hidden. In spec, there is written "All HTML elements may have the hidden content attribute set." As per my observation, in Firefox and IE, we are able to open file system though the "file" element is hidden. In spec, there is written "All HTML elements may have the hidden content attribute set." So in Chrome and Safari, the behavior should be the same as expected. > Looking at the spec, I do read
That's conformance information for authors, not for user agents.
We probably should match Firefox and IE here. Suppressing the dialog in this case isn't buying us any security. (The control could just as easily be "hidden" by being positioned off-screen.)
There's some question about whether the click() method should work at all on this control, but it's behavior shouldn't be different depending on the hidden attribute (unless required by compatibility).
FWIW, we also disable implicit submission when a button is hidden. (In reply to comment #3) > There's some question about whether the click() method should work at all on this control, but it's behavior shouldn't be different depending on the hidden attribute (unless required by compatibility). Mozilla has enabled the .click() method even when the control is otherwise hidden. Using opacity: 0 and setting width/height dimensions are what I usually do for WebKit, though webkit's pseudo-selectors are powerful enough to handle it with more grace. I strongly suggest keeping click, to stay in line with Mozilla. Created attachment 124739 [details]
Proposed patch
Patch v1
Attachment 124739 [details] did not pass style-queue:
Failed to run "['Tools/Scripts/update-webkit']" exit_code: 9
Updating OpenSource
First, rewinding head to replay your work on top of it...
Applying: Fix compilation errors on build-webkit --debug --no-workers on mac.
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging LayoutTests/ChangeLog
CONFLICT (content): Merge conflict in LayoutTests/ChangeLog
Auto-merging LayoutTests/platform/qt/Skipped
CONFLICT (content): Merge conflict in LayoutTests/platform/qt/Skipped
Auto-merging Source/WebCore/ChangeLog
CONFLICT (content): Merge conflict in Source/WebCore/ChangeLog
Failed to merge in the changes.
Patch failed at 0001 Fix compilation errors on build-webkit --debug --no-workers on mac.
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
rebase refs/remotes/origin/master: command returned error: 1
Died at Tools/Scripts/update-webkit line 164.
If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 124739 [details]
Proposed patch
Is it possible to use a similar technique employed in input-file-not-open-without-gesture.html to automatically test this?
(In reply to comment #9) > (From update of attachment 124739 [details]) > Is it possible to use a similar technique employed in input-file-not-open-without-gesture.html to automatically test this? Thanks for taking time to see this. I think it is not possible to automate this test as file dialog opens only when there is user gesture. In input-file-not-open-without-gesture.html the test is other way round where we don't want file dialog to open when not an user gesture. Please do suggest if there is an way to automate. (In reply to comment #10) > I think it is not possible to automate this test as file dialog opens only when there is user gesture. In input-file-not-open-without-gesture.html the test is other way round where we don't want file dialog to open when not an user gesture. Please do suggest if there is an way to automate. But you can use eventSender to generate that "gesture", right? (In reply to comment #11) > (In reply to comment #10) > > I think it is not possible to automate this test as file dialog opens only when there is user gesture. In input-file-not-open-without-gesture.html the test is other way round where we don't want file dialog to open when not an user gesture. Please do suggest if there is an way to automate. > > But you can use eventSender to generate that "gesture", right? Yes, I tried using eventSender but the problem is that when file dialog shows up the current focus is on file dialog and until the file dialog closes the test won't end. As per my understanding even if we generate user event with eventSender and test that body does not get the click event, we need to close the native file open dialog some how so that test ends(I think sending escape key event through eventSender will not have effect on native dialog). (In reply to comment #12) > Yes, I tried using eventSender but the problem is that when file dialog shows up > the current focus is on file dialog and until the file dialog closes the test won't end. input-file-not-open-without-gesture.html uses setTimeout for that. It schedules a call to notifyDone before opening the dialog. > As per my understanding even if we generate user event with eventSender and test that body does not get the click event, we need to close the native file open dialog some how so that test ends(I think sending escape key event through eventSender will not have effect on native dialog). So calling notifyDone in setTimeout won't work? (In reply to comment #13) > input-file-not-open-without-gesture.html uses setTimeout for that. It schedules a call to notifyDone before opening the dialog. Yes, it does and it works fine as file dialog does not open in this test. input-file-not-open-without-gesture.html does timeout if the click happens through eventSender. > So calling notifyDone in setTimeout won't work? It does not work as file dialog is still open and the call FileInputType::handleDOMActivateEvent is not yet complete, I mean the stack has not yet unwinded. The file dialog should not be appearing in DRT and WTR, similarly to how alert() does not start a modal loop. This might require changes in WebCore and test runners. (In reply to comment #15) > The file dialog should not be appearing in DRT and WTR, similarly to how alert() does not start a modal loop. This might require changes in WebCore and test runners. What do you suggest, should we go ahead with this patch and for file dialog not be showing up in DRT and WTR we can file a new bug? It would certainly be better to make this testable and add a test in the same patch. But I didn't override the r+, meaning that I don't object to landing the patch as is. Comment on attachment 124739 [details]
Proposed patch
Given that it's hard to automate the test, it seems fine to land the patch as is.
Comment on attachment 124739 [details] Proposed patch Clearing flags on attachment: 124739 Committed r106538: <http://trac.webkit.org/changeset/106538> All reviewed patches have been landed. Closing bug. |