Modify AX AriaGrabbed test and enable it.

Modify AX AriaGrabbed test and enable it.

This patch makes AccessibilityAriaGrabbed use data URI scheme
for image and adds width and height attributes to image tag
in order to avoid flaky situation.

BUG=453485
R=dmazzoni

Committed: https://crrev.com/f78be2afbe73ec8620cdb404ac34e1b4eafb125e
Cr-Commit-Position: refs/heads/master@{#321306}

[je_julie(Not used), 2015-03-17 00:44:38]

je_julie.kim@samsung.com changed reviewers:
+ dmazzoni@chromium.org

[je_julie(Not used), 2015-03-17 04:06:50]

Hi Dominic,

I investigated the possibility to reproduce the flaky situation.
1) Failed to load image.
-> we can see fallback image. So, it doesn't cause flaky situation.
2) Failed to parse src attribute.
-> hardly possible.
3) Failed to check sub resource loading.
-> It's hard to happen because shouldComplete() in FrameLoader::checkCompleted()
confirms that sub resources are loaded.
4) Canceled loading.
-> When I tested with the code below,
ResourceFetcher::fetchImage{
    ...
    if (!scheduleArchiveLoad(resource.get(), request.resourceRequest()))
        resource->load(this, request.options());
    
    resource->loader()->cancel(); <== I added to cancel loading for testing.
}
After that, I can see the AX tree identified with the issue.

In conclusion,
I'm suspicious about the 4th case but the problem is that I couldn't figure out
how it could be canceled and failed to reproduce this situation.

For now, I changed TC with data URI scheme and width and height attribute
because I think it's more natural to keep image tag for drag and drop tests even
if it doesn't mean anything.
WDTY?

We can have stable image object because data URI scheme doesn't cause sub
resource loading 
and consistent AX image tree with width and height attributes even in the case
that it doesn't have image data.

As to mac trybot failure,
I checked it passed content_browsertests and it failed at some TC related to IPC
and progress(they seem to be flaky).

PTAL.

[dmazzoni, 2015-03-17 05:40:57]

lgtm

This solution seems fine. Since none of this has anything to do with
aria-grabbed I think the solution you have here is good, it's simple.

If we think it's a temporary race condition - i.e. if the accessibility
sometimes loads in the bad state but then gets fixed immediately after, then you
could add @WAIT-FOR to the test - see transition.html for an example of that.
You don't need to change this test, just pointing it out in case you want to use
that in other tests.

https://codereview.chromium.org/1009853002/diff/20001/content/test/data/acces...
File content/test/data/accessibility/aria/aria-grabbed-expected-android.txt
(right):

https://codereview.chromium.org/1009853002/diff/20001/content/test/data/acces...
content/test/data/accessibility/aria/aria-grabbed-expected-android.txt:6:
++++++android.widget.Image clickable
name='wAAAAAAACwAAAAADAAKAAACEoyPAMihnRY0bzo5a8ZQd94oBQA7'
Maybe give the image alt text so that the name is reasonable

[je_julie(Not used), 2015-03-17 23:27:36]

Thanks for your comment.
I added alt for image on test and update test results.

As to @WAIT-FOR, I'll keep it in mind.
PTAL.

https://codereview.chromium.org/1009853002/diff/20001/content/test/data/acces...
File content/test/data/accessibility/aria/aria-grabbed-expected-android.txt
(right):

https://codereview.chromium.org/1009853002/diff/20001/content/test/data/acces...
content/test/data/accessibility/aria/aria-grabbed-expected-android.txt:6:
++++++android.widget.Image clickable
name='wAAAAAAACwAAAAADAAKAAACEoyPAMihnRY0bzo5a8ZQd94oBQA7'
On 2015/03/17 05:40:57, dmazzoni wrote:
> Maybe give the image alt text so that the name is reasonable

Done.

[dmazzoni, 2015-03-18 15:24:30]

lgtm

https://codereview.chromium.org/1009853002/diff/40001/content/test/data/acces...
File content/test/data/accessibility/aria/aria-grabbed-expected-android.txt
(right):

https://codereview.chromium.org/1009853002/diff/40001/content/test/data/acces...
content/test/data/accessibility/aria/aria-grabbed-expected-android.txt:15: <--
End-of-file -->
I don't think you want to check this line in, right?

[je_julie(Not used), 2015-03-19 04:18:10]

Hi Dominic,
PTAL. Thanks.

https://codereview.chromium.org/1009853002/diff/40001/content/test/data/acces...
File content/test/data/accessibility/aria/aria-grabbed-expected-android.txt
(right):

https://codereview.chromium.org/1009853002/diff/40001/content/test/data/acces...
content/test/data/accessibility/aria/aria-grabbed-expected-android.txt:15: <--
End-of-file -->
On 2015/03/18 15:24:29, dmazzoni wrote:
> I don't think you want to check this line in, right?

I removed it. Sorry.

[dmazzoni, 2015-03-19 04:18:43]

The CQ bit was checked by dmazzoni@chromium.org

[dmazzoni, 2015-03-19 04:18:44]

lgtm

[commit-bot: I haz the power, 2015-03-19 04:18:57]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1009853002/60001

[commit-bot: I haz the power, 2015-03-19 06:20:10]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-03-19 06:21:14]

Patchset 4 (id:??) landed as
https://crrev.com/f78be2afbe73ec8620cdb404ac34e1b4eafb125e
Cr-Commit-Position: refs/heads/master@{#321306}