OBJECT alternate content fallback sometimes fails

RESOLVED FIXED

Status

()

Core
Plug-ins
RESOLVED FIXED
16 years ago
3 years ago

People

(Reporter: Greg K., Assigned: johns)

Tracking

(Blocks: 1 bug, {html4, testcase})

Trunk
html4, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -
wanted1.9.2 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PL2:P3][Hixie-P1][HTML4-13.3.1][HTML4-16.5])

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.3+) Gecko/20010821
BuildID:    2001082104

When an IFRAME or OBJECT cannot be loaded for some reason, and the IFRAME or
OBJECT element has contents, the contents should be displayed as an alternative.
Mozilla is presently failing to do this.

Reproducible: Always
Steps to Reproduce:
1. Access the attached testcase

Actual Results:  None of the two IFRAMEs and two OBJECTs displayed their
contents when their src/data values could not be accessed, because the files
could not be found in the first set, and the server could not be found in the
second set. Additionally, the final element, the OBJECT with an unresolvable
hostname in the DATA attribute, displayed an error dialog in addition to failing
to display its' contents.

Expected Results:  The alternate contents of the IFRAMEs and OBJECTs should have
been displayed, and no error dialog should have been shown due to the
unresolvable hostname in the OBJECT DATA.

Alternate content rendering for OBJECT elements seems to have worked until bug
678 was resolved. Also, fixing this will resolve most of the complaints in bug
28586, as most of the error dialogs generated are blocked advertisement IFRAMEs
that usually contain a regular linked image that should be displayed (or itself
allowed to gracefully fail to the IMG ALT).
(Reporter)

Comment 1

16 years ago
Created attachment 47117 [details]
Testcase of IFRAME, OBJECT, and IMG with alternate content
(Reporter)

Updated

16 years ago
Keywords: html4
(Reporter)

Comment 2

16 years ago
Correction: alternate content for OBJECTs whose DATA attribute could not be
found worked prior to bug 678 being fixed. OBJECTs whose data attribute
contained an inaccessible hostname didn't work, though, then or now.

Comment 3

16 years ago
Dupe of bug 65455?
(Reporter)

Comment 4

16 years ago
Bug 65455 is specifically about OBJECTs that lack a TYPE attribute. That WFM at
this point, using Mac/2001082104.

Interestingly, though the simple markup <object>foo</object> does result in foo
being displayed, the equivalent <iframe>foo</iframe> doesn't.
Component: HTML Element → Layout
Summary: Alternate content of embedded elements IFRAME and OBJECT is not displayed → Alternate content of embedded elements IFRAME and OBJECT is not displayed when data/src unreachable
(Reporter)

Comment 5

16 years ago
Also moved to layout since all the other OBJECT contents bugs seems to have been
assigned there.
Keywords: testcase
(Reporter)

Updated

16 years ago
Summary: Alternate content of embedded elements IFRAME and OBJECT is not displayed when data/src unreachable → Alternate content of IFRAME and OBJECT elements isn't displayed when data/src unreachable
(Reporter)

Comment 6

16 years ago
Created attachment 47130 [details]
Revised test suite using bad file: URIs instead of HTTP, and also including bare OBJECT and IFRAME tests

Comment 7

16 years ago
Isn't this a dup of bug 63730 ?

Comment 8

16 years ago
CC'ed
(Reporter)

Comment 9

16 years ago
No, I don't think so. That bug may cover one specific facet of this one, but
this one is much more broad, covering the host of problems with IFRAME and
OBJECT alternate content rendering.

Comment 10

16 years ago
This comment covers all there is to say about it in terms of W3C:

"If the user agent is not able to render the object for whatever reason
(configured not to, lack of resources, wrong architecture, etc.), it must try to
render its contents."

That summary somehow misleading, but disabling image loads is only one simple
way to trigger this bug!
(Reporter)

Comment 11

16 years ago
Right, Neil. The equivalent note for IFRAMEs is, "The contents of the IFRAME
element, on the other hand, should only be displayed by user agents that do not
support frames or are configured not to display frames."
([http://www.w3.org/TR/html4/present/frames.html#h-16.5])

This is actually somewhat different. It doesn't specify that the contents should
be displayed if unavailable, though that would make sense. Certainly an
intrusive error dialog shouldn't be thrown up.

(I must also correct my intial comment on this bug. It's the IFRAME with the
unreachable host that throws up the error dialog, not the OBJECT. Neither
display their alternate content, in any case.)
Sending Clayton's bugs to layout component, HTML Element component is deprecated.
Assignee: clayton → karnaze
QA Contact: bsharma → petersen

Comment 13

16 years ago
Temporarily moving to future until a milestone can be assigned. 
Status: NEW → ASSIGNED
Target Milestone: --- → Future
OS: Mac System 9.x → All
Hardware: Macintosh → All
Whiteboard: [Hixie-P1]
Blocks: 133933

Comment 14

16 years ago
I think plugins have a similar problem.

Comment 15

15 years ago
taking bug...

I think the problem is that we don't do anything in
|nsPluginStreamListenerPeer::OnStartRequest| after we have a chance to examine
the HTTP headers. We need to call back into layout to do some replacing for
alternate content and iframes/images.
Assignee: karnaze → peterl
Status: ASSIGNED → NEW
Priority: -- → P2
Target Milestone: Future → mozilla1.2alpha
(Reporter)

Updated

15 years ago
Attachment #47117 - Attachment is obsolete: true
Whiteboard: [Hixie-P1] → [Hixie-P1][HTML4-13.3.1][HTML4-16.5]

Comment 16

15 years ago
this is a depends on the work that Peter is doing in bug 157554, also the
precise issue is defined in comment #15
Depends on: 157554
Priority: P2 → P3
Whiteboard: [Hixie-P1][HTML4-13.3.1][HTML4-16.5] → [PL2:NA][Hixie-P1][HTML4-13.3.1][HTML4-16.5]
Target Milestone: mozilla1.2alpha → mozilla1.0.2

Updated

15 years ago
Whiteboard: [PL2:NA][Hixie-P1][HTML4-13.3.1][HTML4-16.5] → [PL2:P3][Hixie-P1][HTML4-13.3.1][HTML4-16.5]
Target Milestone: mozilla1.0.2 → mozilla1.1alpha

Updated

15 years ago
Severity: major → normal
Target Milestone: mozilla1.1alpha → mozilla1.2beta

Updated

15 years ago
Blocks: 7954
(Reporter)

Comment 17

15 years ago
Created attachment 97463 [details]
Improved testcase
Attachment #47130 - Attachment is obsolete: true

Comment 18

15 years ago
1.3 beta
Target Milestone: mozilla1.2beta → mozilla1.3beta

Comment 19

15 years ago
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.1b) Gecko/20020814

The valid XHTML 1.1 code below also reproduces this bug when the mng's world
read permission is off. A 468x60 broken image is displayed (surely just the
object element's content should be displayed) AND the link to Mozilla is
rendered (but not the rest of the object element's text). When the mng's world
read permission is on, the mng is rendered correctly (with the link to
webstandards working) AND the link to Mozilla is still rendered (again without
the other text in the object element). This is my first bugzilla post so I hope
this is appropriate and helpful :-)

<p>
<a href="http://www.webstandards.org">
<object data="webstandards.mng" type="video/x-mng" width="468" height="60">
	Web standards banner - Get a browser with MNG support such as <a
href="http://www.mozilla.org">Mozilla</a>
	</object>
	</a>
</p>
No longer blocks: 133933

Comment 20

14 years ago
Note the example given in http://bugzilla.mozilla.org/show_bug.cgi?id=96976#c19
is actually invalid as it can lead to the situation where an a element contains
another a element, this is prohibited, see http://www.w3.org/TR/xhtml1/#prohibitions

In addition to the case contained in the "Improved testcase" attachment I
believe that Mozilla should also handle 404 errors on documents, the data is
unreachable, in a more consistent manner.

Current situation if the object type="image/gif" (for example) and an image is
specified as the data and when requested returns a 404 error the alternate
content is rendered.

If however the type is text/html and the request returns a 404 status the 404
document is used as the content of the object. The alternate content should be
rendered as the data specified is unreachable.
Blocks: 192204
Blocks: 108946

Comment 21

14 years ago
Current (1.5) Mozilla behavior of the attached testcase works for OBJECT cases 2 
and 8, but fails (no rendering at all) for case 5.  There is no error message 
thrown up that needs to be cleared, so that point has been corrected.  IE6 
renders nothing for case 2 but works for case 5 & 8; Opera7 renders nothing for 
case 2, works for case 8, and displays a rectangle with a bad server error for 
case 5.

There are empty IFRAME's shown for case 1 & 7, and an IFRAME containing a Bad 
Request error for case 4.  This is consistent with IE6 and Opera7.  I don't 
think any of the IFRAME cases are in error, per the spec fragment Greg quoted in 
comment 11.

Comment 22

13 years ago
So 1, 4 and 7 in attachment 97463 [details] are invalid per comment 11?

5 in the same attachment is valid (but incorrectly rendered) and this bug is
about that example? Don't we have a bug for that already?
Keywords: qawanted
Priority: P3 → --
Target Milestone: mozilla1.3beta → ---

Comment 23

13 years ago
5 is bug 96579, should this be marked as a duplicate or do we want to do
something with the IFRAME elements?
Depends on: 96579
Blocks: 289480
Depends on: 1156

Comment 24

12 years ago
All that's needed is to fix the iframe renderring.  Can't we borrow code from
the fixes for the object renderring?  I mean, object can be used like an iframe.
Example:

<object type='text/html' data='index.html' style='width: 50%; height: 50%;
border: solid 1px #000;'>Alternate text for index.html not existing.</object>
(the object issues here should be fixed now, by bug 1156's patch)
With trunk from 20051003 the testcase fails on tests 1, 4, 7.

Comment 27

12 years ago
Yes, but it is not really a failure, as the contents of an IFRAME should only been rendered if a browser does not support IFRAMEs or the user has disabled showing them.

Comment 28

12 years ago
I think this bug is fixed. IFRAME is different from OBJECT in terms of fallback. (The summary should therefore be changed as well.)
(Reporter)

Comment 29

12 years ago
Created attachment 205625 [details]
Revised testcase

I revised the testcase to reflect the realities about IFRAME. Using FF 1.5 on Win XP, testcase 5, "object whose DATA specifies a nonexistent server", still fails.
(Reporter)

Comment 30

12 years ago
Oops, forgot to edit the summary.
Summary: Alternate content of IFRAME and OBJECT elements isn't displayed when data/src unreachable → Alternate content of OBJECT elements isn't displayed when data attribute specifies a nonexistent server.

Comment 31

12 years ago
Then, is this bug depends on Bug 56743?
Mozilla doesn't support no-frames mode. If we have this, Mozilla should show alternate content of the IFRAME.
In this case, please revert the summary to the old one.

Bug 56743 - Add option to disable frames/force noframes
https://bugzilla.mozilla.org/show_bug.cgi?id=56743
(Reporter)

Comment 32

12 years ago
(In reply to comment #31)
> Then, is this bug depends on Bug 56743?
> Mozilla doesn't support no-frames mode. If we have this, Mozilla should show
> alternate content of the IFRAME.
> In this case, please revert the summary to the old one.

No, this bug is about alternate contents. If you can turn off frames in Mozilla and the testcase fails in IFRAME handling, then this bug can be about that. Otherwise, it's not relevant.

To be certain, this bug is now purely about example 5 in the testcase.

Comment 33

12 years ago
You should test in Firefox 1.6a where object handling got fixed.
(Reporter)

Comment 34

12 years ago
(In reply to comment #33)
> You should test in Firefox 1.6a where object handling got fixed.

I tested in the latest 1.6a1 nightly. Case 5 is still broken.
(Reporter)

Comment 35

12 years ago
(In reply to comment #33)
> You should test in Firefox 1.6a where object handling got fixed.

I tested in the latest 1.6a1 nightly on Win and Mac. Case 5 is still broken.
case 5 works for me in 2005121309 (seamonkey, winxp)
(Reporter)

Updated

12 years ago
Attachment #97463 - Attachment is obsolete: true
(Reporter)

Comment 37

12 years ago
(In reply to comment #36)
> case 5 works for me in 2005121309 (seamonkey, winxp)

Ah, I may have been mistaken. Now case 5 WFM using Gecko/20051214 Firefox/1.6a1.

I'll re-check on Mac this evening and update.
(Reporter)

Comment 38

12 years ago
Okay, my mistake. Case 5 WFM using Mac Gecko/20051210 Firefox/1.6a1 (likely fixed by the bug referenced in comment 23).
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
so the iframe issues are INVALID?
(Reporter)

Comment 40

12 years ago
(In reply to comment #39)
> so the iframe issues are INVALID?

They're more like UNCONFIRMED. since it's not possible to disable frames and find out how Gecko behaves in that configuration.

Comment 41

12 years ago
So browser.frames.enabled=false does nothing?
then why was this bug morphed to no longer be about iframes?
(Reporter)

Comment 43

11 years ago
Ah, yes, browser.frames.enabled=false works, and the testcase shows we don't handle that properly. So, this is still about both OBJECT and IFRAME. Re-morphing, reopening and trying to write a better summary.

To reproduce, disable frames (see comment 42) and retest attachment 205625 [details].
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: Alternate content of OBJECT elements isn't displayed when data attribute specifies a nonexistent server. → OBJECT and IFRAME alternate content fallback sometimes fails
Assignee: peterl-bugs → nobody
Status: REOPENED → NEW
QA Contact: chrispetersen → layout

Comment 44

11 years ago
*** Bug 335371 has been marked as a duplicate of this bug. ***

Comment 45

10 years ago
http://www.wam-technika.pl/bugs/fallback-bug.html

Could you check if this is the same bug?

Comment 46

10 years ago
(In reply to comment #45)
> http://www.wam-technika.pl/bugs/fallback-bug.html
> Could you check if this is the same bug?

For me, this fails on Firefox 2.0 and works on Firefox 3.0b2. I think this bug has been mostly fixed for Gecko 1.9, which is why it's seeing so little activity now. The changes will not be backported to the 1.8.X line.

Comment 47

8 years ago
Still valid.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4) Gecko/20090427 Shiretoko/3.5b4

Comment 48

8 years ago
(In reply to comment #43)
> Ah, yes, browser.frames.enabled=false works, and the testcase shows we don't
> handle that properly. So, this is still about both OBJECT and IFRAME.
> Re-morphing, reopening and trying to write a better summary.
> 
> To reproduce, disable frames (see comment 42) and retest attachment 205625 [details].

OBJECT is working, IFRAME not, as testcase doesn't show 1,4,7 regardless of state of browser.frames.enabled

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11pre) Gecko/2009050506 GranParadiso/3.0.11pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090505 Shiretoko/3.5b5pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090504 Minefield/3.6a1pre

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090504 SeaMonkey/2.0b1pre

Updated

8 years ago
Flags: wanted1.9.2?
Flags: blocking1.9.2?
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-

Comment 49

8 years ago
Object is not working. See the following file:

<Title>Good day.</Title>
<P>The following is an image.</P>
<div >
    <object data="missing-image.svg" type="image/svg+xml" >
    It is a good day.
    </object> 
</div>

"Missing-image.svg" is missing, but "It is a good day." is not rendered.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
(Assignee)

Comment 50

5 years ago
The load/fallback pathway is being refactored in bug 745030, and should ensure this works
Assignee: nobody → jschoenick
Status: NEW → ASSIGNED
Component: Layout → Plug-ins
Depends on: 745030
No longer depends on: 157554
QA Contact: layout → plugins
The iframe part of this bug report is obsolete. Neither the HTML spec nor Gecko supports turning off iframes.
Summary: OBJECT and IFRAME alternate content fallback sometimes fails → OBJECT alternate content fallback sometimes fails
(Assignee)

Comment 52

5 years ago
This has been fixed for a while, and bug 745030 further cleans things up to ensure proper fallback behavior
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago5 years ago
Resolution: --- → FIXED
(In reply to John Schoenick [:johns] from comment #52)
> This has been fixed for a while, and bug 745030 further cleans things up to
> ensure proper fallback behavior

I noticed for the attached testcase, bug 745030 changes the behaviour of test 2, as its failing now with firefox 17, yet displays ok in 16…
(Assignee)

Comment 54

3 years ago
(In reply to John Drinkwater (:beta) from comment #53)
> (In reply to John Schoenick [:johns] from comment #52)
> > This has been fixed for a while, and bug 745030 further cleans things up to
> > ensure proper fallback behavior
> 
> I noticed for the attached testcase, bug 745030 changes the behaviour of
> test 2, as its failing now with firefox 17, yet displays ok in 16…

I had this flagged in my dashboard for a follow-up, but it appears to work in recent nightlies. Feel free to file a bug if you see otherwise
removing old qawanted tag, if something is needed please re-add
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.