Closed Bug 166591 Opened 17 years ago Closed 11 years ago

<marquee> created dynamically (e.g. innerHTML) is not rendered

Categories

(Core :: Layout, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla1.9.2a1

People

(Reporter: harunaga, Assigned: martijn.martijn)

References

(Depends on 1 open bug, )

Details

Attachments

(2 files, 2 obsolete files)

<marquee> in innerHTML is not "rendered"!!

testcase:
http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=1108

cf. http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.1
"If a user agent encounters an element it does not recognize,
 it should try to render the element's content."
To layout... opening the page in DOM Inspector and drilling down to the inner
html:div in the anonymous content makes the text show...

So we apply the binding. But at no point does the JS run...
Assignee: asa → attinasi
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
QA Contact: asa → petersen
bah
Priority: -- → P3
Target Milestone: --- → Future
I noticed this bug when I set -moz-binding to
url('chrome://xbl-marquee/content/xbl-marquee.xml#marquee-horizontal')
dynamically.  See http://weblogs.mozillazine.org/asa/archives/004372.html.

This code in xbl-marquee.xml is suspicious:

//init needs to be run after the page has loaded in order to calculate the 
//correct height/width
window.addEventListener("load", lambda, false);

Maybe it should somehow check whether load has already fired?
Summary: <marquee> in innerHTML is not "rendered"!! → <marquee> created dynamically (e.g. innerHTML) is not rendered
How about running init() in the constructor and re-initing onload or something?
Has anyone found a way round this problem???
Yes -- don't try using DHTML with marquees.
Assignee: attinasi → nobody
Priority: P3 → --
QA Contact: chrispetersen → core.layout
Target Milestone: Future → ---
Depends on: 299231
Attached file appendchild testcase
Note that the url testcase won't be fixed by following the suggestion in
comment 4, because of bug 299231.
This testcase would be fixed by following the suggestion in comment 7.
Attached patch patch (obsolete) — Splinter Review
Er, I meant in comment 4.

I think removing the addeventlistener and replacing it by a timer would be
possible if the patch from bug 235564 got used. It would fix the attached
testcase, but not the url testcase.
But by adding the margin dynamically in the constructor instead of the
xbl:content, the marquee contents would at least be visible. This would also be
the case when you have js turned off.
Depends on: 347174
Depends on: 235564
This works at least since Fx3

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081127 Minefield/3.1b3pre

->WFM
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
I can still see the bug, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081127 Minefield/3.1b3pre
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Attached patch patch (obsolete) — Splinter Review
This now makes use of the fix for bug 347174.
Attachment #187789 - Attachment is obsolete: true
Attachment #357700 - Flags: review?(bzbarsky)
Comment on attachment 357700 [details] [diff] [review]
patch

>+++ b/layout/reftests/reftest.list
>+# mathml/
>+include marquee/reftest.list

s/mathml/marquee/

Looks good with that.
Attachment #357700 - Flags: superreview+
Attachment #357700 - Flags: review?(bzbarsky)
Attachment #357700 - Flags: review+
Attachment #357700 - Attachment is obsolete: true
Attachment #357774 - Flags: superreview+
Attachment #357774 - Flags: review+
Keywords: checkin-needed
Checked in.
http://hg.mozilla.org/mozilla-central/rev/8adfeca108cd
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Keywords: checkin-needed
Target Milestone: --- → mozilla1.9.2a1
Assignee: nobody → martijn.martijn
Target Milestone: mozilla1.9.2a1 → ---
Target Milestone: --- → mozilla1.9.2a1
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.