Bug 85605 – [EFL] [DRT] Gardening some failure cases on EFL port

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit EFL

[Sudarsana Nagineni (babu)]

This is for gardening 8 failure cases on EFL port.

fast/canvas/fillText-shadow.html
fast/dom/Window/window-lookup-precedence.html 
fast/dom/Window/window-properties-performance.html
fast/dom/constructed-objects-prototypes.html 
fast/dom/frame-loading-via-document-write.html 
fast/dom/navigator-detached-no-crash.html
http/tests/navigation/postredirect-basic.html
http/tests/navigation/postredirect-goback1.html

[Sudarsana Nagineni (babu)]

Created attachment 140199 [details]
patch

Updated baselines and moved http navigation failures to test_expectations.txt

[Sudarsana Nagineni (babu)]

Created attachment 140210 [details]
patch

rebased

[Raphael Kubo da Costa (:rakuco)]

Comment on attachment 140210 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=140210&action=review

> LayoutTests/platform/efl/fast/canvas/fillText-shadow-expected.txt:43
> +FAIL imgdata[3] should be 255. Was 191.

Are you sure this is correct?

> LayoutTests/platform/efl/fast/dom/Window/window-lookup-precedence-expected.txt:418
> +FAIL win['defaultStatus'] should be undefined (of type undefined). Was  (of type string).
> +FAIL win['defaultStatus'] should be undefined (of type undefined). Was  (of type string).
> +FAIL win['defaultstatus'] should be undefined (of type undefined). Was  (of type string).
> +FAIL win['defaultstatus'] should be undefined (of type undefined). Was  (of type string).
> +FAIL win['name'] should be undefined (of type undefined). Was  (of type string).
> +FAIL win['name'] should be undefined (of type undefined). Was  (of type string).
> +FAIL win['status'] should be undefined (of type undefined). Was  (of type string).
> +FAIL win['status'] should be undefined (of type undefined). Was  (of type string).

Are these failures expected?

> LayoutTests/platform/efl/fast/dom/Window/window-properties-performance-expected.txt:5
> +window.performance.memory.jsHeapSizeLimit [undefined]

Is this correct?

> LayoutTests/platform/efl/test_expectations.txt:288
> +// Issue related to battery status and vibration API
> +BUGWK85594 : fast/dom/navigator-detached-no-crash.html = TEXT

I was thinking of not skipping this one because it just needs some attention -- our expectations are different because the EFL port supports the battery and vibration APIs, I'm just not sure about that connect thing.

[Sudarsana Nagineni (babu)]

Comment on attachment 140210 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=140210&action=review

>> LayoutTests/platform/efl/fast/canvas/fillText-shadow-expected.txt:43
>> +FAIL imgdata[3] should be 255. Was 191.
> 
> Are you sure this is correct?

Results are same as in GTK port and looks correct after font metrics changes.

>> LayoutTests/platform/efl/fast/dom/Window/window-lookup-precedence-expected.txt:418
>> +FAIL win['status'] should be undefined (of type undefined). Was  (of type string).
> 
> Are these failures expected?

These results are same as in GTK port.

>> LayoutTests/platform/efl/fast/dom/Window/window-properties-performance-expected.txt:5
>> +window.performance.memory.jsHeapSizeLimit [undefined]
> 
> Is this correct?

Same as in qt port and looks correct after r77495.

>> LayoutTests/platform/efl/test_expectations.txt:288
>> +BUGWK85594 : fast/dom/navigator-detached-no-crash.html = TEXT
> 
> I was thinking of not skipping this one because it just needs some attention -- our expectations are different because the EFL port supports the battery and vibration APIs, I'm just not sure about that connect thing.

We have a bug now. We can investigate the issue and unksip when we have a fix.

[Raphael Kubo da Costa (:rakuco)]

(In reply to comment #4)
> (From update of attachment 140210 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=140210&action=review
> 
> >> LayoutTests/platform/efl/fast/canvas/fillText-shadow-expected.txt:43
> >> +FAIL imgdata[3] should be 255. Was 191.
> > 
> > Are you sure this is correct?
> 
> Results are same as in GTK port and looks correct after font metrics changes.

Hmm, OK.

> >> LayoutTests/platform/efl/fast/dom/Window/window-lookup-precedence-expected.txt:418
> >> +FAIL win['status'] should be undefined (of type undefined). Was  (of type string).
> > 
> > Are these failures expected?
> 
> These results are same as in GTK port.

Sorry, I highlighted the wrong part of the file.

-PASS win['HTMLDataListElement'] == '[object HTMLDataListElementConstructor]' is true
-PASS win['HTMLDataListElement'] == '[object HTMLDataListElementConstructor]' is true
+FAIL win['HTMLDataListElement'] should be null (of type object). Was undefined (of type undefined).
+FAIL win['HTMLDataListElement'] should be null. Was [object HTMLInputElement].

This is the tricky part.

> >> LayoutTests/platform/efl/fast/dom/Window/window-properties-performance-expected.txt:5
> >> +window.performance.memory.jsHeapSizeLimit [undefined]
> > 
> > Is this correct?
> 
> Same as in qt port and looks correct after r77495.

Indeed, makes sense. Too bad the base expectation is V8-focused :P

> >> LayoutTests/platform/efl/test_expectations.txt:288
> >> +BUGWK85594 : fast/dom/navigator-detached-no-crash.html = TEXT
> > 
> > I was thinking of not skipping this one because it just needs some attention -- our expectations are different because the EFL port supports the battery and vibration APIs, I'm just not sure about that connect thing.
> 
> We have a bug now. We can investigate the issue and unksip when we have a fix.

OK.

[Sudarsana Nagineni (babu)]

Comment on attachment 140210 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=140210&action=review

>>>> LayoutTests/platform/efl/fast/dom/Window/window-lookup-precedence-expected.txt:418
>>>> +FAIL win['status'] should be undefined (of type undefined). Was  (of type string).
>>> 
>>> Are these failures expected?
>> 
>> These results are same as in GTK port.
> 
> Sorry, I highlighted the wrong part of the file.
> 
> -PASS win['HTMLDataListElement'] == '[object HTMLDataListElementConstructor]' is true
> -PASS win['HTMLDataListElement'] == '[object HTMLDataListElementConstructor]' is true
> +FAIL win['HTMLDataListElement'] should be null (of type object). Was undefined (of type undefined).
> +FAIL win['HTMLDataListElement'] should be null. Was [object HTMLInputElement].
> 
> This is the tricky part.

ENABLE_DATALIST is OFF on elf build, and that's the reason for this failure. We can update platform expectations when we enable the datalist support.

[Sudarsana Nagineni (babu)]

Comment on attachment 140210 [details]
patch

This needs to rebased again after 85604.

[Sudarsana Nagineni (babu)]

Comment on attachment 140210 [details]
patch

rebasing not required since the patch in 85604 failed to land.

[WebKit Review Bot]

Comment on attachment 140210 [details]
patch

Clearing flags on attachment: 140210

Committed r116118: <http://trac.webkit.org/changeset/116118>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.