Move navigation-induced hiding of form-validation-bubble to the browser process.

Move navigation-induced hiding of form-validation-bubble to the browser process.

Moving hiding of the form validation bubble to the browser process has
the following benefits:
- It allows simplifying/removing code from Blink (in particular it
  allows removing some of the code added in r459701).
- It makes the hiding immune against compromised renderers.
- It makes the hiding work even if ViewHostMsg_HideValidationMessage IPC
  gets filtered out (i.e. see CanSendWhileSwappedOut method in
  content::SwappedOutMessages).  This in turn will allow relanding
  of r479538.

BUG=733940
TEST=Manually verified that bugs 733940, 704560, 673163 are still fixed.

Review-Url: https://codereview.chromium.org/2949593003
Cr-Commit-Position: refs/heads/master@{#481681}
Committed: https://chromium.googlesource.com/chromium/src/+/15399f887a0e8498253dc4496446eee83158e96a

[Łukasz Anforowicz, 2017-06-19 22:12:24]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-19 22:13:02]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-20 00:22:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-20 00:22:03]

Dry run: This issue passed the CQ dry run.

[Łukasz Anforowicz, 2017-06-20 17:21:44]

Description was changed from

==========
Move navigation-induced hiding of form-validation-bubble to the browser process.

Moving hiding of the form validation bubble to the browser process has
the following benefits:
- It allows simplifying/removing code from Blink.
- It makes the hiding immune against compromised renderers.
- It makes the hiding work even if ViewHostMsg_HideValidationMessage IPC
  gets filtered out (i.e. see CanSendWhileSwappedOut method in
  content::SwappedOutMessages).

BUG=733940
==========

to

==========
Move navigation-induced hiding of form-validation-bubble to the browser process.

Moving hiding of the form validation bubble to the browser process has
the following benefits:
- It allows simplifying/removing code from Blink.
- It makes the hiding immune against compromised renderers.
- It makes the hiding work even if ViewHostMsg_HideValidationMessage IPC
  gets filtered out (i.e. see CanSendWhileSwappedOut method in
  content::SwappedOutMessages).  This in turn will allow relanding
  of r479538.

BUG=733940
TEST=Manually verified that bugs 733940, 704560, 673163 are still fixed.
==========

[Łukasz Anforowicz, 2017-06-20 17:24:02]

Description was changed from

==========
Move navigation-induced hiding of form-validation-bubble to the browser process.

Moving hiding of the form validation bubble to the browser process has
the following benefits:
- It allows simplifying/removing code from Blink.
- It makes the hiding immune against compromised renderers.
- It makes the hiding work even if ViewHostMsg_HideValidationMessage IPC
  gets filtered out (i.e. see CanSendWhileSwappedOut method in
  content::SwappedOutMessages).  This in turn will allow relanding
  of r479538.

BUG=733940
TEST=Manually verified that bugs 733940, 704560, 673163 are still fixed.
==========

to

==========
Move navigation-induced hiding of form-validation-bubble to the browser process.

Moving hiding of the form validation bubble to the browser process has
the following benefits:
- It allows simplifying/removing code from Blink (in particular it
  allows removing some of the code added in r459701).
- It makes the hiding immune against compromised renderers.
- It makes the hiding work even if ViewHostMsg_HideValidationMessage IPC
  gets filtered out (i.e. see CanSendWhileSwappedOut method in
  content::SwappedOutMessages).  This in turn will allow relanding
  of r479538.

BUG=733940
TEST=Manually verified that bugs 733940, 704560, 673163 are still fixed.
==========

[Łukasz Anforowicz, 2017-06-20 17:27:18]

lukasza@chromium.org changed reviewers:
+ tkent@chromium.org

[Łukasz Anforowicz, 2017-06-20 17:27:19]

tkent@, could you PTAL?  This CL replaces some of renderer-side changes from
your r459701 with browser-side clean-up (in
WebContentsImpl::CancelActiveAndPendingDialogs).

I think that in the long-term we might want to draw form-validation-bubbles
entirely on the renderer generated drawing surfaces (please see
https://crbug.com/734729), but I think landing this CL is desirable in the
short-term:
- It simplifies code.
- It allows relanding of r479538.

[tkent, 2017-06-20 23:14:52]

third_party/WebKit lgtm.
Looks very simple. Thanks!

[Łukasz Anforowicz, 2017-06-20 23:28:21]

lukasza@chromium.org changed reviewers:
+ alexmos@chromium.org

[Łukasz Anforowicz, 2017-06-20 23:28:22]

alexmos@, could you PTAL?

[Łukasz Anforowicz, 2017-06-21 00:53:05]

Description was changed from

==========
Move navigation-induced hiding of form-validation-bubble to the browser process.

Moving hiding of the form validation bubble to the browser process has
the following benefits:
- It allows simplifying/removing code from Blink (in particular it
  allows removing some of the code added in r459701).
- It makes the hiding immune against compromised renderers.
- It makes the hiding work even if ViewHostMsg_HideValidationMessage IPC
  gets filtered out (i.e. see CanSendWhileSwappedOut method in
  content::SwappedOutMessages).  This in turn will allow relanding
  of r479538.

BUG=733940
TEST=Manually verified that bugs 733940, 704560, 673163 are still fixed.
==========

to

==========
Move navigation-induced hiding of form-validation-bubble to the browser process.

Moving hiding of the form validation bubble to the browser process has
the following benefits:
- It allows simplifying/removing code from Blink (in particular it
  allows removing some of the code added in r459701).
- It makes the hiding immune against compromised renderers.
- It makes the hiding work even if ViewHostMsg_HideValidationMessage IPC
  gets filtered out (i.e. see CanSendWhileSwappedOut method in
  content::SwappedOutMessages).  This in turn will allow relanding
  of r479538.

BUG=733940
TEST=Manually verified that bugs 733940, 704560, 673163 are still fixed.
==========

[Łukasz Anforowicz, 2017-06-21 00:53:18]

+estade@

On 2017/06/20 23:14:52, tkent wrote:
> Looks very simple. Thanks!

All the credit for the simplicity of this CL goes to estade@ - the CL just
follows his suggestion from https://crbug.com/733940#c7.  Thanks estade@! :-)

[Evan Stade, 2017-06-21 15:47:30]

estade@chromium.org changed reviewers:
+ estade@chromium.org

[Evan Stade, 2017-06-21 15:47:31]

hurray for -40 production LOC

https://codereview.chromium.org/2949593003/diff/1/content/browser/web_content...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/2949593003/diff/1/content/browser/web_content...
content/browser/web_contents/web_contents_impl.cc:4681:
delegate_->HideValidationMessage(this);
I think we can remove this now?

[Łukasz Anforowicz, 2017-06-21 16:30:10]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-21 16:30:32]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Łukasz Anforowicz, 2017-06-21 16:31:13]

https://codereview.chromium.org/2949593003/diff/1/content/browser/web_content...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/2949593003/diff/1/content/browser/web_content...
content/browser/web_contents/web_contents_impl.cc:4681:
delegate_->HideValidationMessage(this);
On 2017/06/21 15:47:30, Evan Stade wrote:
> I think we can remove this now?

Ooops, I should have noticed this.  Done.

[commit-bot: I haz the power, 2017-06-21 19:14:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-21 19:14:54]

Dry run: This issue passed the CQ dry run.

[alexmos, 2017-06-21 21:32:27]

This looks good, but one sanity check: CancelActiveAndPendingDialogs is called
when any frame on the page navigates.  Is it correct to hide the form validation
message when an unrelated frame that doesn't actually contain the form commits a
navigation?

Also, not for this CL, but something we might need to file a bug for: do these
validation messages work when sent from OOPIFs?  Seems like they're sent through
RenderView, so I'd expect that they will be dropped when the RenderView is
swapped out, plus there might be trouble with coordinates in
ViewHostMsg_ShowValidationMessage, etc.  FWIW, I tried out the sample code from
your test in an OOPIF and saw no validation popup (whereas it worked fine in the
main frame or local subframe).

[Łukasz Anforowicz, 2017-06-22 17:47:17]

On 2017/06/21 21:32:27, alexmos wrote:
> This looks good, but one sanity check: CancelActiveAndPendingDialogs is called
> when any frame on the page navigates.  Is it correct to hide the form
validation
> message when an unrelated frame that doesn't actually contain the form commits
a
> navigation?

Good catch - I haven't considered this :-(.  


I think the behavior after this CL is fine, because:

- The form validation bubble disappears after clicking anywhere else on the page
  (this would include navigations initated by the user)

- The form validation bubble disappears on its own after 5 seconds
  (so even if the bubble disappears because of a javascript navigation in
another frame,
   it won't be very different from disappearing because of a timeout)

- All the various issues will go away if we start drawing the form validation
  bubble inside the renderer - https://crbug.com/736009


OTOH, maybe I should open a separate bug to track this - especially since this
also covers other dialogs (I think it is surprising that a navigation in
another, possibly cross-site frame can cancel a dialog trigerred by another
frame).


> Also, not for this CL, but something we might need to file a bug for: do these
> validation messages work when sent from OOPIFs?  Seems like they're sent
through
> RenderView, so I'd expect that they will be dropped when the RenderView is
> swapped out, plus there might be trouble with coordinates in
> ViewHostMsg_ShowValidationMessage, etc.  FWIW, I tried out the sample code
from
> your test in an OOPIF and saw no validation popup (whereas it worked fine in
the
> main frame or local subframe).

Good catch - I've opened https://crbug.com/736009 to track this.

[alexmos, 2017-06-22 18:06:46]

LGTM.  Thanks for filing the OOPIF bug!

On 2017/06/22 17:47:17, Łukasz A. wrote:
> On 2017/06/21 21:32:27, alexmos wrote:
> > This looks good, but one sanity check: CancelActiveAndPendingDialogs is
called
> > when any frame on the page navigates.  Is it correct to hide the form
> validation
> > message when an unrelated frame that doesn't actually contain the form
commits
> a
> > navigation?
> 
> Good catch - I haven't considered this :-(.  
> 
> 
> I think the behavior after this CL is fine, because:
> 
> - The form validation bubble disappears after clicking anywhere else on the
page
>   (this would include navigations initated by the user)
> 
> - The form validation bubble disappears on its own after 5 seconds
>   (so even if the bubble disappears because of a javascript navigation in
> another frame,
>    it won't be very different from disappearing because of a timeout)
> 
> - All the various issues will go away if we start drawing the form validation
>   bubble inside the renderer - https://crbug.com/736009

OK, sounds reasonable to keep this behavior for now.

> 
> OTOH, maybe I should open a separate bug to track this - especially since this
> also covers other dialogs (I think it is surprising that a navigation in
> another, possibly cross-site frame can cancel a dialog trigerred by another
> frame).

You might also want to run this by Avi and see whether he thinks there's a
problem here.

[Łukasz Anforowicz, 2017-06-22 18:17:10]

lukasza@chromium.org changed reviewers:
+ avi@chromium.org

[Łukasz Anforowicz, 2017-06-22 18:19:54]

avi@, can you PTAL @ the question / concern below?

On 2017/06/22 18:06:46, alexmos wrote:
> LGTM.  Thanks for filing the OOPIF bug!
> 
> On 2017/06/22 17:47:17, Łukasz A. wrote:
> > On 2017/06/21 21:32:27, alexmos wrote:
> > > This looks good, but one sanity check: CancelActiveAndPendingDialogs is
> called
> > > when any frame on the page navigates.  Is it correct to hide the form
> > validation
> > > message when an unrelated frame that doesn't actually contain the form
> commits
> > a
> > > navigation?
> > 
> > Good catch - I haven't considered this :-(.  
> > 
> > 
> > I think the behavior after this CL is fine, because:
> > 
> > - The form validation bubble disappears after clicking anywhere else on the
> page
> >   (this would include navigations initated by the user)
> > 
> > - The form validation bubble disappears on its own after 5 seconds
> >   (so even if the bubble disappears because of a javascript navigation in
> > another frame,
> >    it won't be very different from disappearing because of a timeout)
> > 
> > - All the various issues will go away if we start drawing the form
validation
> >   bubble inside the renderer - https://crbug.com/736009
> 
> OK, sounds reasonable to keep this behavior for now.
> 
> > 
> > OTOH, maybe I should open a separate bug to track this - especially since
this
> > also covers other dialogs (I think it is surprising that a navigation in
> > another, possibly cross-site frame can cancel a dialog trigerred by another
> > frame).
> 
> You might also want to run this by Avi and see whether he thinks there's a
> problem here.

Avi: Do you think it is a problem that we discard dialogs in frame A, when frame
B navigates?  Should I open a bug for this?

[Avi (use Gerrit), 2017-06-22 18:37:02]

On 2017/06/22 18:19:54, Łukasz A. wrote:
> avi@, can you PTAL @ the question / concern below?
> 
> On 2017/06/22 18:06:46, alexmos wrote:
> > LGTM.  Thanks for filing the OOPIF bug!
> > 
> > On 2017/06/22 17:47:17, Łukasz A. wrote:
> > > On 2017/06/21 21:32:27, alexmos wrote:
> > > > This looks good, but one sanity check: CancelActiveAndPendingDialogs is
> > called
> > > > when any frame on the page navigates.  Is it correct to hide the form
> > > validation
> > > > message when an unrelated frame that doesn't actually contain the form
> > commits
> > > a
> > > > navigation?
> > > 
> > > Good catch - I haven't considered this :-(.  
> > > 
> > > 
> > > I think the behavior after this CL is fine, because:
> > > 
> > > - The form validation bubble disappears after clicking anywhere else on
the
> > page
> > >   (this would include navigations initated by the user)
> > > 
> > > - The form validation bubble disappears on its own after 5 seconds
> > >   (so even if the bubble disappears because of a javascript navigation in
> > > another frame,
> > >    it won't be very different from disappearing because of a timeout)
> > > 
> > > - All the various issues will go away if we start drawing the form
> validation
> > >   bubble inside the renderer - https://crbug.com/736009
> > 
> > OK, sounds reasonable to keep this behavior for now.
> > 
> > > 
> > > OTOH, maybe I should open a separate bug to track this - especially since
> this
> > > also covers other dialogs (I think it is surprising that a navigation in
> > > another, possibly cross-site frame can cancel a dialog trigerred by
another
> > > frame).
> > 
> > You might also want to run this by Avi and see whether he thinks there's a
> > problem here.
> 
> Avi: Do you think it is a problem that we discard dialogs in frame A, when
frame
> B navigates?  Should I open a bug for this?

I'm not sure I fully understand your question.

Right now, before this CL lands, are we dismissing JavaScript dialogs in one
frame when a different frame commits? Are you planning on changing this?

If you are changing this behavior, that would be web-visible and you would need
an Intent before you did that.

[Łukasz Anforowicz, 2017-06-22 19:18:28]

On 2017/06/22 18:37:02, Avi (ping after 24h) wrote:
> On 2017/06/22 18:19:54, Łukasz A. wrote:
> > avi@, can you PTAL @ the question / concern below?
> > 
> > On 2017/06/22 18:06:46, alexmos wrote:
> > > LGTM.  Thanks for filing the OOPIF bug!
> > > 
> > > On 2017/06/22 17:47:17, Łukasz A. wrote:
> > > > On 2017/06/21 21:32:27, alexmos wrote:
> > > > > This looks good, but one sanity check: CancelActiveAndPendingDialogs
is
> > > called
> > > > > when any frame on the page navigates.  Is it correct to hide the form
> > > > validation
> > > > > message when an unrelated frame that doesn't actually contain the form
> > > commits
> > > > a
> > > > > navigation?
> > > > 
> > > > Good catch - I haven't considered this :-(.  
> > > > 
> > > > 
> > > > I think the behavior after this CL is fine, because:
> > > > 
> > > > - The form validation bubble disappears after clicking anywhere else on
> the
> > > page
> > > >   (this would include navigations initated by the user)
> > > > 
> > > > - The form validation bubble disappears on its own after 5 seconds
> > > >   (so even if the bubble disappears because of a javascript navigation
in
> > > > another frame,
> > > >    it won't be very different from disappearing because of a timeout)
> > > > 
> > > > - All the various issues will go away if we start drawing the form
> > validation
> > > >   bubble inside the renderer - https://crbug.com/736009
> > > 
> > > OK, sounds reasonable to keep this behavior for now.
> > > 
> > > > 
> > > > OTOH, maybe I should open a separate bug to track this - especially
since
> > this
> > > > also covers other dialogs (I think it is surprising that a navigation in
> > > > another, possibly cross-site frame can cancel a dialog trigerred by
> another
> > > > frame).
> > > 
> > > You might also want to run this by Avi and see whether he thinks there's a
> > > problem here.
> > 
> > Avi: Do you think it is a problem that we discard dialogs in frame A, when
> frame
> > B navigates?  Should I open a bug for this?
> 
> I'm not sure I fully understand your question.
> 
> Right now, before this CL lands, are we dismissing JavaScript dialogs in one
> frame when a different frame commits? Are you planning on changing this?
> 
> If you are changing this behavior, that would be web-visible and you would
need
> an Intent before you did that.

Even without this CL we are be dismissing JavaScript dialogs in one frame when a
different frame commits.  I've just verified this on a dev (61.0.3128.3) with
the following repro steps:
1. Navigate to http://anforowicz.github.io/form-validation-bubble
2. Click "navigate with delay" in the right frame
3. Click "open a dialog" in the left frame
4. Wait 10 seconds until the navigation triggerred in step2 happens.
5. Observe: the dialog from step3 is dismissed.

[Avi (use Gerrit), 2017-06-22 19:22:11]

On 2017/06/22 19:18:28, Łukasz A. wrote:
> On 2017/06/22 18:37:02, Avi (ping after 24h) wrote:
> > On 2017/06/22 18:19:54, Łukasz A. wrote:
> > > avi@, can you PTAL @ the question / concern below?
> > > 
> > > On 2017/06/22 18:06:46, alexmos wrote:
> > > > LGTM.  Thanks for filing the OOPIF bug!
> > > > 
> > > > On 2017/06/22 17:47:17, Łukasz A. wrote:
> > > > > On 2017/06/21 21:32:27, alexmos wrote:
> > > > > > This looks good, but one sanity check: CancelActiveAndPendingDialogs
> is
> > > > called
> > > > > > when any frame on the page navigates.  Is it correct to hide the
form
> > > > > validation
> > > > > > message when an unrelated frame that doesn't actually contain the
form
> > > > commits
> > > > > a
> > > > > > navigation?
> > > > > 
> > > > > Good catch - I haven't considered this :-(.  
> > > > > 
> > > > > 
> > > > > I think the behavior after this CL is fine, because:
> > > > > 
> > > > > - The form validation bubble disappears after clicking anywhere else
on
> > the
> > > > page
> > > > >   (this would include navigations initated by the user)
> > > > > 
> > > > > - The form validation bubble disappears on its own after 5 seconds
> > > > >   (so even if the bubble disappears because of a javascript navigation
> in
> > > > > another frame,
> > > > >    it won't be very different from disappearing because of a timeout)
> > > > > 
> > > > > - All the various issues will go away if we start drawing the form
> > > validation
> > > > >   bubble inside the renderer - https://crbug.com/736009
> > > > 
> > > > OK, sounds reasonable to keep this behavior for now.
> > > > 
> > > > > 
> > > > > OTOH, maybe I should open a separate bug to track this - especially
> since
> > > this
> > > > > also covers other dialogs (I think it is surprising that a navigation
in
> > > > > another, possibly cross-site frame can cancel a dialog trigerred by
> > another
> > > > > frame).
> > > > 
> > > > You might also want to run this by Avi and see whether he thinks there's
a
> > > > problem here.
> > > 
> > > Avi: Do you think it is a problem that we discard dialogs in frame A, when
> > frame
> > > B navigates?  Should I open a bug for this?
> > 
> > I'm not sure I fully understand your question.
> > 
> > Right now, before this CL lands, are we dismissing JavaScript dialogs in one
> > frame when a different frame commits? Are you planning on changing this?
> > 
> > If you are changing this behavior, that would be web-visible and you would
> need
> > an Intent before you did that.
> 
> Even without this CL we are be dismissing JavaScript dialogs in one frame when
a
> different frame commits.  I've just verified this on a dev (61.0.3128.3) with
> the following repro steps:
> 1. Navigate to http://anforowicz.github.io/form-validation-bubble
> 2. Click "navigate with delay" in the right frame
> 3. Click "open a dialog" in the left frame
> 4. Wait 10 seconds until the navigation triggerred in step2 happens.
> 5. Observe: the dialog from step3 is dismissed.

If we already have this behavior, then I'm not too worried.

[Łukasz Anforowicz, 2017-06-22 19:22:57]

The CQ bit was checked by lukasza@chromium.org

[Łukasz Anforowicz, 2017-06-22 19:22:57]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org
Link to the patchset: https://codereview.chromium.org/2949593003/#ps20001
(title: "Remove now unnecessary call from WebContentsImpl::RenderViewTerminated
to delegate_->HideValidation…")

[commit-bot: I haz the power, 2017-06-22 19:23:18]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-22 21:59:17]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1498159377238220,
"parent_rev": "f36920f8a01eb8ad3a0e891cd401627cd74ed3af", "commit_rev":
"15399f887a0e8498253dc4496446eee83158e96a"}

[commit-bot: I haz the power, 2017-06-22 21:59:30]

Description was changed from

==========
Move navigation-induced hiding of form-validation-bubble to the browser process.

Moving hiding of the form validation bubble to the browser process has
the following benefits:
- It allows simplifying/removing code from Blink (in particular it
  allows removing some of the code added in r459701).
- It makes the hiding immune against compromised renderers.
- It makes the hiding work even if ViewHostMsg_HideValidationMessage IPC
  gets filtered out (i.e. see CanSendWhileSwappedOut method in
  content::SwappedOutMessages).  This in turn will allow relanding
  of r479538.

BUG=733940
TEST=Manually verified that bugs 733940, 704560, 673163 are still fixed.
==========

to

==========
Move navigation-induced hiding of form-validation-bubble to the browser process.

Moving hiding of the form validation bubble to the browser process has
the following benefits:
- It allows simplifying/removing code from Blink (in particular it
  allows removing some of the code added in r459701).
- It makes the hiding immune against compromised renderers.
- It makes the hiding work even if ViewHostMsg_HideValidationMessage IPC
  gets filtered out (i.e. see CanSendWhileSwappedOut method in
  content::SwappedOutMessages).  This in turn will allow relanding
  of r479538.

BUG=733940
TEST=Manually verified that bugs 733940, 704560, 673163 are still fixed.

Review-Url: https://codereview.chromium.org/2949593003
Cr-Commit-Position: refs/heads/master@{#481681}
Committed:
https://chromium.googlesource.com/chromium/src/+/15399f887a0e8498253dc4496446...
==========

[commit-bot: I haz the power, 2017-06-22 21:59:33]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/15399f887a0e8498253dc4496446...

[dcheng, 2017-06-23 08:34:15]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/2956593003/ by dcheng@chromium.org.

The reason for reverting is: Causing failures on WebKit Linux Trusty Leak.

({"numberOfLiveDocuments":[1,2],"numberOfLiveNodes":[4,62],"numberOfLiveResources":[0,2],"numberOfLiveSuspendableObjects":[2,3]}).

[dcheng, 2017-06-23 08:35:15]

dcheng@chromium.org changed reviewers:
+ dcheng@chromium.org

[dcheng, 2017-06-23 08:35:16]

https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Trusty...
is a failure.

Repro command:
testing/xvfb.py third_party/WebKit/Tools/Scripts/run-webkit-tests --seed 4
--no-show-results --full-results-html --clobber-old-results
--exit-after-n-failures 5000 --exit-after-n-crashes-or-timeouts 100
--additional-expectations third_party/WebKit/LayoutTests/LeakExpectations
--time-out-ms 48000 --enable-leak-detection
fast/forms/file/file-input-empty-validation.html -t builder

GN args:
is_component_build = false
is_debug = false
strip_absolute_paths_from_debug_symbols = true
use_goma = true