[CSS3 Backgrounds and Borders] The border image area should be empty if border-style is none and border-image-width is not set

[tapir]

According  w3c css3-border-image to the specification. (See http://www.w3.org/TR/css3-background/#border-image)
The border-image properties do not affect layout: layout of the box, its content, and surrounding content is based on the ‘border-width’ and ‘border-style’ properties only.

But in WebKit , if Element has a valid 'border-image'  style  but sets 'border-style' to none, WebKit does render the border, which is against the CSS spec.

See one of WebKit layout tests: http://trac.webkit.org/browser/trunk/LayoutTests/fast/borders/border-image-omit-right-slice.html, in this test, the div should not have border, but the expectation file does have, please see 
http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/fast/borders/border-image-omit-right-slice-expected.txt

[Johnny(Jianning) Ding]

Created attachment 170092 [details]
how some main stream browsers render border-image with setting border-style as None

Yes, it's a WebKit bug, other main stream render engines seem right. See the attached snapshot

[Johnny(Jianning) Ding]

@David, I saw the patch which honored the border-image even if border-style is none was introduced in http://trac.webkit.org/changeset/10357 and http://trac.webkit.org/changeset/10909. 
But as tapir (the reportrt of this bug) pointed, that behavior is against the description of feature "border images" in current css3-background spec(http://www.w3.org/TR/css3-background/#border-images), which causes that WebKit doesn't render the "border images" as other main stream render engines if border-style is none.

I'd like to upload a patch to fix it.

[Johnny(Jianning) Ding]

Created attachment 171235 [details]
initial patch, just for reference. (some layout tests need to rebaseline)

[Jeongeun Kim]

Johnny, this issue seems to be valid. Are you still working on it?
If not, can I look into it?

[Jeongeun Kim]

I understood that border image is used instead of border-style.
border-image is used in place of the border-styles. 

http://www.w3.org/TR/css3-background/#border-image-source
"If the value is ‘none’ or if the image cannot be displayed (or the property doesn't apply), the border styles will be used; otherwise the element's borders are invisible and the border image is drawn as described in the sections below."

The current behavior from Webkit is correct, even if other browser engines work differently.

Please close this issue with "INVALID".

[Simon Fraser (smfr)]

Sounds good.

[Philippe Wittenbergh]

I disagree with this resolution: If border-style is set to none, or no border is specified (the initial value for border is ‘none’ anyway), then no border-image should be painted. From the spec, for ‘border-style’:

‘none’
No border. Color and width are ignored (i.e., the border has width 0). Note this means that the initial value of ‘border-image-width’ will also resolve to zero.

http://dev.w3.org/csswg/css-backgrounds/#the-border-style


This means that a border-style *must* be specified with a value other than ‘none’ in order for the border-image to be painted. WebKit (and Bink - Opera tested) is also wrong for the case where no border is specified (given that the initial value for border-style is ‘none’).

Internet explorer and firefox are correct.

testcase(s) : http://dev.l-c-n.com/CSS3_border-background/border-image_border-style-none.html

[Jeongeun Kim]

(In reply to comment #7)
> http://dev.w3.org/csswg/css-backgrounds/#the-border-style
> This means that a border-style *must* be specified with a value other than ‘none’ in order for the border-image to be painted. WebKit (and Bink - Opera tested) is also wrong for the case where no border is specified (given that the initial value for border-style is ‘none’).
> Internet explorer and firefox are correct.

Hi Philippe,
If you look into http://dev.w3.org/csswg/css-backgrounds/#the-border-style,
you can find 'These properties set the style of the border, unless there is a border image.'
border-style is applied when there is no border image.
Regards,

[Philippe Wittenbergh]

(In reply to comment #8)

> If you look into http://dev.w3.org/csswg/css-backgrounds/#the-border-style,
> you can find 'These properties set the style of the border, unless there is a border image.'
> border-style is applied when there is no border image.

As I noted, for the value 'none' the spec specifies:
> Note this means that the initial value of ‘border-image-width’ will also resolve to zero.

I would tend to agree that there is a lack of clarity in the spec about this, though.

[Boris Zbarsky]

Reopening.  This bug was filed based on a discussion with the spec editors.  If you think the spec is unclear, please file spec issues as needed, but the working group resolution was in fact that "border-style: none" means no border-image.

[Boris Zbarsky]

And more to the point, the spec is quite clear that if "border-style: none" then the computed border-width is 0 and since the default value of "border-image-width" is 1, that computes to 0 as well (1*0 = 0 and all that).

[Gérard Talbot (no longer involved)]

Another test (submitted to CSS3 Backgrounds and Borders test suite):

http://test.csswg.org/suites/css-backgrounds-3_dev/nightly-unstable/html4/border-image-slice-003.htm

[Adenilson Cavalcanti Silva]

I can work on this.


Adenilson

[Gérard Talbot (no longer involved)]

(In reply to comment #0)
> one of WebKit layout tests:
> http://trac.webkit.org/browser/trunk/LayoutTests/fast/borders/border-image-
> omit-right-slice.html

The following border-image shorthand declaration (found in that test, still fetchable)

	border-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAIAAAACUFjqAAAAAXNSR0IArs4c6QAAAUFJREFUGNMBNgHJ/gPcUkznH/n8lGR5YkMIIMDXFhgoVNnfqeM5dbre55MDGkF/U6tMmi12K6QBpfkB4H3NyPZAiyjm6kp//uPtAA4pZhHPJ8xbkSop4chy5ecPsVSqkC03ozAmk77SOwOHR+fDXmoF5UUJU9YsnVfehg/iLC7p3etC3w3LEA8D0eGf/DZozPPzoSSX6gTVlQ/L4Ylt4SrFiOgqNDQPAPvl/JQuLv33xK66eAgGCn+OAIUu1Fugs2hsZNIB6gPhrZ80q7sXNUEuIE7EGNC5Dc2ExcIe9tseb4r7usAAralzLgdas9URX21wGUqSgDnf/jMydhxMIEx4w9TtAfCQPsbi30EEVABXFJYnOZgfbQK3CLkwg6PDGG27KwOYF7jD+sIHhdwoUyILAF5sv/6bI6S56fbULB5OToUjFpS7UHGrVgAAAABJRU5ErkJggg==) 1 2 3;

is invalid. The CSS validator also confirms that.

6.7. Border Image Shorthand syntax is:

	<‘border-image-source’> || <‘border-image-slice’> [ / <‘border-image-width’> | / <‘border-image-width’>? / <‘border-image-outset’> ]? || <‘border-image-repeat’>
http://www.w3.org/TR/css3-background/#the-border-image

The declaration misses 2 forward slashes.

border-image: url("cat.png") 1 / 2 / 3; /* is valid */

border-image: url("cat.png") 1 2 3; /* is invalid */

- - - - - - - - - - - 

(In reply to comment #5)
> I understood that border image is used instead of border-style.
> border-image is used in place of the border-styles. 

"
The border image is drawn inside an area called the border image area. This is an area whose boundaries *_by default_* correspond to the border box
"

and then border image area can be extended out of the border box, beyond the border box and into the margin area thanks to border-image-outset. So the border image can fill the content area, the padding area, the border area and even the margin area of an element.

[Adenilson Cavalcanti Silva]

For reference, Blink fix is at (pending review):
https://codereview.chromium.org/1457323004/

I should upload a WebKit patch soon.

[Gérard Talbot (no longer involved)]

Adenilson,

I created and submitted the following 3 tests into the CSS3 Backgrounds and Borders test suite 2 days ago:

http://test.csswg.org/suites/css-backgrounds-3_dev/nightly-unstable/html4/border-image-width-005.htm

http://test.csswg.org/suites/css-backgrounds-3_dev/nightly-unstable/html4/border-image-width-006.htm

http://test.csswg.org/suites/css-backgrounds-3_dev/nightly-unstable/html4/border-image-width-007.htm

Chrome 48.0.2564.10 fails those 3 tests. Sorry: I do not have Safari 9.0.2.

On the other hand, Firefox 42, IE11 and Edge 12 pass those 3 tests.

Those tests specifically have a 'border-style: none' and a 'border-width: 0px' on the element but the way border image area is designed (if computed border-image-width is not 0px), the border image can still paint the border box and even outside of it.

I probably should open another bug report for this...

[Adenilson Cavalcanti Silva]

Created attachment 266169 [details]
For review only, missing rebaselines

For review only, missing rebaselines.

[Adenilson Cavalcanti Silva]

I looked in both https://trac.webkit.org/wiki/Rebaseline and https://trac.webkit.org/wiki/TestExpectations and I'm a bit unsure how to proceed with creating new rebaselines for the patched tests.

Suggestions?

[Gérard Talbot (no longer involved)]

(In reply to comment #17)
> Created attachment 266169 [details]
> For review only, missing rebaselines
> 
> For review only, missing rebaselines.

Adenilson,

In attachment 266169 [details]

a/LayoutTests/fast/borders/border-image-omit-right-slice.html (Lines 17-22)

seems to me to be *_a bad test_* because the border-image syntax is not valid:

 border-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAIAAAACUFjqAAAAAXNSR0IArs4c6QAAAUFJREFUGNMBNgHJ/gPcUkznH/n8lGR5YkMIIMDXFhgoVNnfqeM5dbre55MDGkF/U6tMmi12K6QBpfkB4H3NyPZAiyjm6kp//uPtAA4pZhHPJ8xbkSop4chy5ecPsVSqkC03ozAmk77SOwOHR+fDXmoF5UUJU9YsnVfehg/iLC7p3etC3w3LEA8D0eGf/DZozPPzoSSX6gTVlQ/L4Ylt4SrFiOgqNDQPAPvl/JQuLv33xK66eAgGCn+OAIUu1Fugs2hsZNIB6gPhrZ80q7sXNUEuIE7EGNC5Dc2ExcIe9tseb4r7usAAralzLgdas9URX21wGUqSgDnf/jMydhxMIEx4w9TtAfCQPsbi30EEVABXFJYnOZgfbQK3CLkwg6PDGG27KwOYF7jD+sIHhdwoUyILAF5sv/6bI6S56fbULB5OToUjFpS7UHGrVgAAAABJRU5ErkJggg==) 1 2 3;

should be instead/rather

 border-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAIAAAACUFjqAAAAAXNSR0IArs4c6QAAAUFJREFUGNMBNgHJ/gPcUkznH/n8lGR5YkMIIMDXFhgoVNnfqeM5dbre55MDGkF/U6tMmi12K6QBpfkB4H3NyPZAiyjm6kp//uPtAA4pZhHPJ8xbkSop4chy5ecPsVSqkC03ozAmk77SOwOHR+fDXmoF5UUJU9YsnVfehg/iLC7p3etC3w3LEA8D0eGf/DZozPPzoSSX6gTVlQ/L4Ylt4SrFiOgqNDQPAPvl/JQuLv33xK66eAgGCn+OAIUu1Fugs2hsZNIB6gPhrZ80q7sXNUEuIE7EGNC5Dc2ExcIe9tseb4r7usAAralzLgdas9URX21wGUqSgDnf/jMydhxMIEx4w9TtAfCQPsbi30EEVABXFJYnOZgfbQK3CLkwg6PDGG27KwOYF7jD+sIHhdwoUyILAF5sv/6bI6S56fbULB5OToUjFpS7UHGrVgAAAABJRU5ErkJggg==) 1 / 2 / 3;

Again, I am enclined to believe we should open/create a new bug report, specifically about this particular issue (for such test). It is difficult or awkward for me to do so if I do not have and do not use Safari.

- - - - - - 

In a/LayoutTests/fast/borders/border-image-should-not-display.html (+21 lines) 

line 9   /* If border style is not set (default is None), border-image

line 10    should be ignored.

In all fairness, such comment is not necessarly true and is not always (or generally) true. In comment 16 of this bug report, you can see 3 tests where 'border-style' is explicitly set to 'none' and there is indeed a rendered border-image.

- - - - - - 

I will create and open right now a bug report about comment 16. If your patch is making Safari pass those 3 tests in comment 16, then I will let you just resolve it accordingly as WORKSFORME or FIXED. Okay?

- - - - - - 

Unfortunately, I can not help you regarding the new rebaselines for the patched tests issue.

[Build Bot]

Comment on attachment 266169 [details]
For review only, missing rebaselines

Attachment 266169 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/478008

Number of test failures exceeded the failure limit.

[Build Bot]

Created attachment 266170 [details]
Archive of layout-test-results from ews100 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 266169 [details]
For review only, missing rebaselines

Attachment 266169 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/478009

Number of test failures exceeded the failure limit.

[Build Bot]

Created attachment 266171 [details]
Archive of layout-test-results from ews104 for mac-yosemite-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews104  Port: mac-yosemite-wk2  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 266169 [details]
For review only, missing rebaselines

Attachment 266169 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/478012

Number of test failures exceeded the failure limit.

[Build Bot]

Created attachment 266172 [details]
Archive of layout-test-results from ews117 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews117  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Gérard Talbot (no longer involved)]

> I will create and open right now a bug report about comment 16. If your
> patch is making Safari pass those 3 tests in comment 16, then I will let you
> just resolve it accordingly as WORKSFORME or FIXED. Okay?

Bug 151612 - [CSS3 Backgrounds and Borders] border image area can exist even if 'border-style' of element is 'none'

[Gérard Talbot (no longer involved)]

tapir,

Please can you replace 
[css border]
with
[CSS3 Backgrounds and Borders]
in the Summary field?

Also, can you add 
HasReduction, W3CTest
in the keywords field?

Also, the Summary could be more precise, more correct. Something like

[CSS3 Backgrounds and Borders] Drawing area to be painted is zero, nil when computed border-width of element is 0 and also when border-image-width is set (or defaults) to a number

You can do this since you are bug reporter.

[BJ Burg]

(In reply to comment #27)
> tapir,
> 
> Please can you replace 
> [css border]
> with
> [CSS3 Backgrounds and Borders]
> in the Summary field?
> 
> Also, can you add 
> HasReduction, W3CTest
> in the keywords field?
> 
> Also, the Summary could be more precise, more correct. Something like
> 
> [CSS3 Backgrounds and Borders] Drawing area to be painted is zero, nil when
> computed border-width of element is 0 and also when border-image-width is
> set (or defaults) to a number
> 
> You can do this since you are bug reporter.

WebKit's bugzilla doesn't use a summary field. If you would like to have EditBugs flag on your account (so that you can edit keywords, open/close/retitle), let me know and it will be arranged.

[Adenilson Cavalcanti Silva]

Created attachment 266365 [details]
Including updated test results

[Adenilson Cavalcanti Silva]

For reference, to generate new test results, just run: 
./run-webkit-tests --debug --reset-results path/to/test

[Build Bot]

Comment on attachment 266365 [details]
Including updated test results

Attachment 266365 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/502403

New failing tests:
svg/as-border-image/svg-as-border-image.html
svg/as-border-image/svg-as-border-image-2.html
animations/cross-fade-border-image-source.html
fast/css/image-set-value-not-removed-crash.html

[Build Bot]

Created attachment 266372 [details]
Archive of layout-test-results from ews104 for mac-yosemite-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews104  Port: mac-yosemite-wk2  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 266365 [details]
Including updated test results

Attachment 266365 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/502515

New failing tests:
svg/as-border-image/svg-as-border-image.html
svg/as-border-image/svg-as-border-image-2.html
animations/cross-fade-border-image-source.html
fast/css/image-set-value-not-removed-crash.html

[Build Bot]

Created attachment 266375 [details]
Archive of layout-test-results from ews112 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews112  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Adenilson Cavalcanti Silva]

Created attachment 266376 [details]
Fixed last tests.

[Gérard Talbot (no longer involved)]

> Created attachment 266376 [details]

Adenilson,

In
(-)a/LayoutTests/fast/borders/border-image-source.html (+1 lines) 

  border-image-source: url("resources/border-image.png") !important
  border-style: solid;

should be instead


  border-image-source: url("resources/border-image.png") !important;
  border-style: solid;

The CSS validator will report the error (missing ";" separating the 2 declarations)

- - - - - - - 

The error reported in comment 14 and in comment 19 is still there.


border-image: url("cat.png") 1 / 2 / 3; /* is valid */

border-image: url("cat.png") 1 2 3; /* is INvalid */

[Gérard Talbot (no longer involved)]

> border-image: url("cat.png") 1 2 3; /* is INvalid */


After a closer look, this actually could be valid... it would mean that border-slice-width uses 3 number values and that both border-image-width uses the default value (1) and border-image-outset uses default value (0). Doh!

border-image:	<‘border-image-source’> || <‘border-image-slice’> [ / <‘border-image-width’> | / <‘border-image-width’>? / <‘border-image-outset’> ]? || <‘border-image-repeat’>

So, now, the CSS validator has a bug!

[Simon Fraser (smfr)]

Comment on attachment 266376 [details]
Fixed last tests.

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

> LayoutTests/ChangeLog:9
> +        Ensure that WebKit will be compliant to css-backgrounds spec where
> +        a border with an image will only be rendered if there is a style defined.

I would like to see a link to the appropriate part of the spec here.

[Adenilson Cavalcanti Silva]

Created attachment 266395 [details]
Safari vanilla X patched (w3c test case)

[Adenilson Cavalcanti Silva]

Created attachment 266398 [details]
Adding links to the spec + w3c discussion.

[WebKit Commit Bot]

Comment on attachment 266398 [details]
Adding links to the spec + w3c discussion.

Clearing flags on attachment: 266398

Committed r192955: <http://trac.webkit.org/changeset/192955>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Ryan Haddad]

A lot of these tests are failing on Windows. It is at least the ones below:

animations/cross-fade-border-image-source.html
fast/borders/border-image-border-radius.html
fast/borders/border-image-outset-split-inline-vertical-lr.html
fast/borders/border-image-outset-split-inline.html
fast/borders/border-image-scaled.html
fast/borders/scaled-border-image.html
svg/as-border-image/svg-as-border-image-2.html
svg/as-border-image/svg-as-border-image.html

[WebKit Commit Bot]

Re-opened since this is blocked by bug 151776

[Adenilson Cavalcanti Silva]

Saving the conversation on IRC:

[3:11pm] Savago: ryanhaddad: I think I understand what happened.
[3:11pm] Savago: I generated new test results for mac.
[3:11pm] Savago: But not for Windows.
[3:11pm] Savago: This is why the failures are ‘text’ only in most cases.
[3:11pm] Savago: IIRC, there is a way to ask a bot to generate those results, right?
[3:13pm] Savago: ryanhaddad: https://trac.webkit.org/wiki/Rebaseline
[3:15pm] Savago: So, I guess there are at least 2 ways to fix it: a) generate the new baselines using the bot (assuming that really works); b) (worst case) just skip the affected tests in Windows.
[3:16pm] ryanhaddad: Savago seems reasonable to me

[Adenilson Cavalcanti Silva]

It was brought to my attention by Mike Taylor@Mozilla that this quirky is required by mobile gmail: https://bugzilla.mozilla.org/show_bug.cgi?id=995140#c18

Thanks to the backport of this patch to Blink, Alan Cutter@Google filed an internal bug in Gmail (b/25961635) concerning the incorrect use of border-image (i.e. not defining the border style and expecting a border-image to be rendered).

It also seems that MS Edge had to implement the quirky(!) to workaround gmail, I will contact someone from MS to double check.

It may make sense to push this when Gmail/GCalendar have fixed their code. As I've have further information I will post here.

[Adenilson Cavalcanti Silva]

Created attachment 266512 [details]
mobile gcalendar: Vanilla Safari X Patched Minibrowser

Buttons will be rendered with no rounded borders on patched WebKit.

[David Vest]

Just to make it clear, the patch (mentioned in comment #15) hasn't landed in Blink yet.

[Adenilson Cavalcanti Silva]

Created attachment 266557 [details]
MS Edge

Just confirmed that MS Edge had to implement the quirk, please see attached screenshot.

[Adenilson Cavalcanti Silva]

Created attachment 266791 [details]
Skipping Windows Tests, adding ref. to follow up bug and www-style post

For review only, we got to hear when gcalendar/gmail will fix their code before landing this.

[Adenilson Cavalcanti Silva]

An update qw gcalendar mobile was fixed:
https://code.google.com/p/chromium/issues/detail?id=559258#c37

and gmail mobile is coming next.

[Adenilson Cavalcanti Silva]

An update as gcalendar mobile was fixed:
https://code.google.com/p/chromium/issues/detail?id=559258#c37

and gmail mobile is coming next.

[Adenilson Cavalcanti Silva]

And it seems that google is currently fixing mobile gmail:
https://github.com/webcompat/web-bugs/issues/1333#issuecomment-184457918

[Adenilson Cavalcanti Silva]

Update: both mobile gcalendar and gmail are fixed. 

Also learned from MS that they fixed Edge and will make it available to public soon.

I think we can proceed with this now, I will upload an updated patch soon.

[Adenilson Cavalcanti Silva]

Created attachment 295376 [details]
Rebased with current trunk

We can land this now as gcalendar and gmail are fixed.

[Adenilson Cavalcanti Silva]

Created attachment 295377 [details]
Fixed CL formatting

[Build Bot]

Comment on attachment 295377 [details]
Fixed CL formatting

Attachment 295377 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/2561989

New failing tests:
fast/borders/border-image-01.html
fast/borders/border-image-rotate-transform.html
fast/borders/scaled-border-image.html
fast/borders/border-image-source.html
fast/borders/border-image-outset.html
fast/hidpi/image-set-border-image-dynamic.html
fast/borders/border-image-border-radius.html
fast/hidpi/image-set-border-image-comparison.html
fast/borders/border-image-scaled.html
fast/borders/border-fit-2.html
fast/writing-mode/border-image-vertical-rl.html
fast/borders/border-image-slice-constrained.html
fast/borders/border-image-side-reduction.html
fast/hidpi/image-set-border-image-simple.html
animations/cross-fade-border-image-source.html
fast/borders/border-image-repeat.html
fast/borders/border-image-massive-scale.html
fast/borders/border-image-longhand.html
fast/writing-mode/border-image-vertical-lr.html
fast/borders/border-image-scrambled.html
fast/borders/border-image-omit-right-slice.html
fast/borders/border-image-scale-transform.html
fast/borders/border-image-slices.html
fast/borders/border-image-outset-in-shorthand.html
fast/writing-mode/border-image-horizontal-bt.html

[Build Bot]

Created attachment 295379 [details]
Archive of layout-test-results from ews122 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews122  Port: ios-simulator-wk2  Platform: Mac OS X 10.11.6

[Adenilson Cavalcanti Silva]

As ios-sim bot is red, it seems that I will have to update the test expectations for platform/ios-simulator too.

[Radar WebKit Bug Importer]

<rdar://problem/34603784>

[Brady Eidson]

Comment on attachment 295377 [details]
Fixed CL formatting

Patches that have been up for review since 2016 are almost certainly too stale to be relevant to trunk in their current form.

If this patch is still important please rebase it and post it for review again.

[Simon Fraser (smfr)]

The patch needed a few tweaks.

[Simon Fraser (smfr)]

Created attachment 436459 [details]
Patch

[Simon Fraser (smfr)]

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

[Adenilson Cavalcanti]

@Simon: Thanks a lot for bringing this back to life, I really appreciate it.

It is really cool to see this getting done after all this years (I miss the good old days of working on Webkit).
:-)

[Simon Fraser (smfr)]

Created attachment 436522 [details]
Patch

[Simon Fraser (smfr)]

https://trac.webkit.org/changeset/281724/webkit

[Arcady Goldmints-Orlov]

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