Bug 23203 – Multiple background properties are not retrievable via DOM method getComputedStyle

• Component: DOM
• Status: RESOLVED FIXED

[Faruk Ates]

Any element that has multiple backgrounds specified on it will not return any but the first background image's properties via DOM methods, though it does correctly return the background color (of which there can be only one anyway).

See URL for the testcase.

Testcase also shows the odd return value for the alpha property in rgba(); that bug is already filed here:
https://bugs.webkit.org/show_bug.cgi?id=23202

[Faruk Ates]

Just to elaborate on this radar, the CSS 3 spec says that the Computed Value for multiple background images should be:

"as specified, but with URIs made absolute"

Source:
http://www.w3.org/TR/css3-background/#the-background-image

[Faruk Ates]

New discovery: when setting multiple background images via el.style.cssText and retrieving them directly via el.style.backgroundImage, the value is correct: all images are listed with absolute paths, as per the spec.

So this is just not working in getComputedStyle, only. I've adjusted the Summary.

[NovakP]

Hi, any progress on this bug? This still doesn't work in WebKit two years after reporting.

[Simon Fraser (smfr)]

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

[Simon Fraser (smfr)]

I started working on a patch for this.

[Simon Fraser (smfr)]

Created attachment 72543 [details]
Patch

[Dave Hyatt]

Comment on attachment 72543 [details]
Patch

r=me, but do something about "size.size." heh.

[Simon Fraser (smfr)]

http://trac.webkit.org/changeset/71049

[WebKit Review Bot]

http://trac.webkit.org/changeset/71049 might have broken Qt Linux Release
The following tests are not passing:
fast/backgrounds/multiple-backgrounds-computed-style.html

[Alexey Proskuryakov]

+++ trunk/LayoutTests/fast/backgrounds/script-tests/TEMPLATE.html	2010-11-01 20:39:48 UTC (rev 71049)

This is evil. Splitting tests into .html and .js only adds indirection and wastes time for the person investigating failures. Please see e.g. <http://trac.webkit.org/browser/trunk/LayoutTests/fast/speech/input-text-language-tag.html> for what I think is a better pattern for script tests.

[Eric Seidel (no email)]

Evil might be a strong word.  It's been a historically recommended pattern.

I think someone should write a document on good layout test design, but I think using the existing script-test pattern doesn't count as "evil". :)

[Simon Fraser (smfr)]

I don't really care if the JS in in the test file or a separate file, but I was just following (possibly outdated) convention.

[Alexey Proskuryakov]

I don't think this was ever a common convention for tests outside fast/js, but it certainly did have vocal proponents.