Bug 141699 – [GTK] Layout Tests for experimental <attachment> element are failing since added

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Marcos Chavarría Teijeiro (irc: chavaone)]

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

[Arcady Goldmints-Orlov]

For what it's worth, the tests all fail because the attachment element is not enabled on GTK.

[Tim Horton]

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?

[Arcady Goldmints-Orlov]

*** Bug 177534 has been marked as a duplicate of this bug. ***

[Arcady Goldmints-Orlov]

*** Bug 142268 has been marked as a duplicate of this bug. ***

[Arcady Goldmints-Orlov]

*** Bug 142269 has been marked as a duplicate of this bug. ***

[Arcady Goldmints-Orlov]

*** Bug 191402 has been marked as a duplicate of this bug. ***

[Arcady Goldmints-Orlov]

*** Bug 212199 has been marked as a duplicate of this bug. ***

[Arcady Goldmints-Orlov]

*** Bug 194009 has been marked as a duplicate of this bug. ***

[Michael Catanzaro]

(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?

[Tim Horton]

(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.

[Michael Catanzaro]

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.

[Tim Horton]

I agree! (and am surprised it's not already that way)

[Sam Weinig]

(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).

[Tim Horton]

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.

[Sam Weinig]

Not shocked, just disappointed.

[Arcady Goldmints-Orlov]

Created attachment 442887 [details]
[fast-cq] Patch

[Arcady Goldmints-Orlov]

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.

[EWS]

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].

[Radar WebKit Bug Importer]

<rdar://problem/84829919>