47664 - Broken url() generated content should not be rendered [GC]

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Hixie (not reading bugmail)]

At the moment, generated content that includes url() content that points to
invalid, broken, unrecognised or missing content results in a truncated version
of the filename being inserted instead.

I am guessing that what is *actually* happening is that we are inserting an
anonymous IMG frame which is then resulting in the Alternate Text codepath being
used. This is wrong -- we should just be including nothing if the url() cannot
be inserted.

STEPS TO REPRODUCE:
   Look at the test at the bottom (labelled "Silly") of 
      http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/content/3.html

ACTUAL RESULTS:
   :before { content: "This is " url(in.html) "valid."; } => "This is invalid."

EXPECTED RESULTS:
   :before { content: "This is " url(in.html) "valid."; } => "This is valid."

(Note that the testcase actually uses different content to test this.)

TESTED ON:
   Windows 2000 Commerical Build 6.0.17.2000080404.
   Mac 8.5 Commerical Build 6.0.17.2000080304.

Comment 1

[Marc Attinasi]

Eech. Will investigate...

Comment 2

[Marc Attinasi]

It's ugly, and it's bad. The problem is that the image frame is created, and it 
is much later and completly out of context that the 'failure to load' 
notification comes in and the Alt Text path is taken. I wonder why we are 
creating an image frame to begin with? From my reading of the CSS2 it says that 
we must ignore this resource if we cannot display it, but it does not say that 
it has to be an image. Hmmmm. It does not work even if the resource does exist; 
unless it is a valid image it still shows the alt-text representation.

Ian, why have you nominated this for beta3? Seems sort of minor, although it is 
obviously incorrect.

Comment 3

[Hixie (not reading bugmail)]

Marc: In case it was an easy fix, and because it is a standards compliance issue
(as opposed to a standards support issue).

Comment 4

[Marc Attinasi]

OK - It looks to me like we could easily avoid doing the ALT-text frame if we 
could somehow identify the content element or frame as being generated content 
in the method nsCSSFrameConstructor::CantRenderReplacedElement. In there, we go 
through the logic of determining if it is an IMG and then creating an alternate 
frame and replacing the old frame with it. If we could -tag- the content node as 
'generated' using an attribute or something then we could text it and avoid 
constructing the alternate frame. I'll try setting an attribute on the content 
when it is generated and testing for that attribute in the 
nsCSSFrameConstructor::CantRenderReplacedElement method, but it may take me some 
time.

Comment 5

[Marc Attinasi]

Denying for beta3: not deemed ultra-critical.

Note: If the IsSynthetic() method on nsIContent was actually implemented this
would be pretty easy. However, that method is not implemented anywhere so it is
very tough to determine...

Comment 6

[Tobias Burnus]

(Is there a bug concerning the content of html|text url() not being embedded?)

Comment 7

[Tobias Burnus]

(regarding my question: yes, bug 678)
I cannot reproduce this with 2000-10-04-21/Linux. I get 'valid' and not
'invalid' and I don't get a '2' in the URL testcase.
That is: it works for me.

Comment 8

[Hixie (not reading bugmail)]

Heh, good point. Because we no longer use the filename in working out the 
alternate text. I need to find a way of showing the problem again.

So this is now WORKSFORME, because although the bug exists, it is no longer a 
bug because the problem can no longer occur. I wonder if it occurs if the 
element causing the generated content has a title attribute...

And of course, url(2.html) should work on that page, and doesn't...

Comment 9

[Madhur Bhatia]

any progress with this bug?

Comment 10

[Andrew Hagen]

Editing for grammar.

Old Summary: Broken url() generated content should render nothing [GC]

New Summary: Broken url() generated content should not be rendered [GC]

Comment 11

[Boris Zbarsky [:bzbarsky]]

So... the testcase at http://www.hixie.ch/tests/evil/mixed/content/3.html seems
to workforme.  Can we have a testcase for this bug?

Comment 12

[Hixie (not reading bugmail)]

WORKSFORME as per comment 8.