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
Created attachment 140199 [details] patch Updated baselines and moved http navigation failures to test_expectations.txt
Created attachment 140210 [details] patch rebased
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.
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.
(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.
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.
Comment on attachment 140210 [details] patch This needs to rebased again after 85604.
Comment on attachment 140210 [details] patch rebasing not required since the patch in 85604 failed to land.
Comment on attachment 140210 [details] patch Clearing flags on attachment: 140210 Committed r116118: <http://trac.webkit.org/changeset/116118>
All reviewed patches have been landed. Closing bug.