The fast/attachment/attachment-disabled-rendering.html and fast/attachment/attachment-rendering.html layout tests are failing since they were added on r180193 (https://trac.webkit.org/changeset/180193). The diffs are the following: * fast/attachment/attachment-disabled-rendering.html --- /home/ch01/wk-tools/layout-test-results/fast/attachment/attachment-disabled-rendering-expected.txt +++ /home/ch01/wk-tools/layout-test-results/fast/attachment/attachment-disabled-rendering-actual.txt @@ -3,9 +3,9 @@ layer at (0,0) size 800x600 RenderBlock {HTML} at (0,0) size 800x600 RenderBody {BODY} at (8,8) size 784x576 - RenderBlock {P} at (0,0) size 784x18 - RenderText {#text} at (0,0) size 766x18 - text run at (0,0) width 766: "This tests that attachments don't have a custom renderer when they are disabled. This test must be run in the test runner." - RenderBlock (anonymous) at (0,34) size 784x0 + RenderBlock {P} at (0,0) size 784x17 + RenderText {#text} at (0,0) size 750x17 + text run at (0,0) width 750: "This tests that attachments don't have a custom renderer when they are disabled. This test must be run in the test runner." + RenderBlock (anonymous) at (0,33) size 784x0 RenderInline {ATTACHMENT} at (0,0) size 0x0 RenderText {#text} at (0,0) size 0x0 * fast/attachment/attachment-rendering.html --- /home/ch01/wk-tools/layout-test-results/fast/attachment/attachment-rendering-expected.txt +++ /home/ch01/wk-tools/layout-test-results/fast/attachment/attachment-rendering-actual.txt @@ -2,10 +2,10 @@ RenderView at (0,0) size 800x600 layer at (0,0) size 800x600 RenderBlock {HTML} at (0,0) size 800x600 - RenderBody {BODY} at (8,8) size 784x584 - RenderBlock {P} at (0,0) size 784x18 - RenderText {#text} at (0,0) size 326x18 - text run at (0,0) width 326: "This tests that attachments have a custom renderer." - RenderBlock (anonymous) at (0,34) size 784x200 - RenderAttachment {ATTACHMENT} at (0,0) size 200x200 + RenderBody {BODY} at (8,8) size 784x576 + RenderBlock {P} at (0,0) size 784x17 + RenderText {#text} at (0,0) size 318x17 + text run at (0,0) width 318: "This tests that attachments have a custom renderer." + RenderBlock (anonymous) at (0,33) size 784x0 + RenderInline {ATTACHMENT} at (0,0) size 0x0 RenderText {#text} at (0,0) size 0x0
For what it's worth, the tests all fail because the attachment element is not enabled on GTK.
FWIW I would expect Gtk to skip all of fast/attachment; it's not a web-exposed feature nor one that I imagine you need?
*** Bug 177534 has been marked as a duplicate of this bug. ***
*** Bug 142268 has been marked as a duplicate of this bug. ***
*** Bug 142269 has been marked as a duplicate of this bug. ***
*** Bug 191402 has been marked as a duplicate of this bug. ***
*** Bug 212199 has been marked as a duplicate of this bug. ***
*** Bug 194009 has been marked as a duplicate of this bug. ***
(In reply to Tim Horton from comment #2) > FWIW I would expect Gtk to skip all of fast/attachment; it's not a > web-exposed feature nor one that I imagine you need? So... what is HTML attachment element? I'm curious that we have an HTML element that is not web-exposed? Is it something private for Mac applications only?
(In reply to Michael Catanzaro from comment #9) > (In reply to Tim Horton from comment #2) > > FWIW I would expect Gtk to skip all of fast/attachment; it's not a > > web-exposed feature nor one that I imagine you need? > > So... what is HTML attachment element? I'm curious that we have an HTML > element that is not web-exposed? > > Is it something private for Mac applications only? For apps (both iOS and macOS), yes; it represents a 'file' in the contenteditable area in Mail.
It should probably be skipped in the global expectations then, and unskipped in Cocoa port expectations, so that every port doesn't have to skip it separately.
I agree! (and am surprised it's not already that way)
(In reply to Tim Horton from comment #12) > I agree! (and am surprised it's not already that way) (I think we really should consider proposing <attachment> for actual web usage, perhaps under a different name, at some point. It seems like it could have its uses).
Likely! Could be useful for mail/notes/etc. web apps. I think it would need a significantly expanded JS interface, though; the way it shook out requires a lot of interaction to happen through the native API, sadly.
Not shocked, just disappointed.
Created attachment 442887 [details] [fast-cq] Patch
For now I would like to just mark the tests as skipped on GLIB and close this bug. If and when the attachment element gets on track to standardization, we can open another bug for its implementation on glib platforms.
Committed r285066 (243708@main): <https://commits.webkit.org/243708@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 442887 [details].
<rdar://problem/84829919>