322288 - ynet.co.il - High CPU usage caused by DHTML scrolling "marquee"-like news ticker/message

Status: RESOLVED WORKSFORME

(Tech Evangelism Graveyard :: Hebrew, defect)

Description

[Gérard Talbot]

There has been at least 9 bugs reporting the same problem: bug 280645, bug 235694, bug 260340, bug 289681, bug 297457, bug 315444, bug 316240, bug 322250, bug 137584

Setting Severity to major

bug 137584 comment #29 has measured the cpu activity; bug 260340 comment #1 also and so have others.

Article:
DHTML Demonstrations Using DOM/Style:Stock Ticker
http://developer.mozilla.org/en/docs/DHTML_Demonstrations_Using_DOM/Style:Stock_Ticker

Example (right to left):
http://developer.mozilla.org/samples/StockTicker/

Example (from bottom to top):
xbMarquee in Simplified Chinese
http://devedge-temp.mozilla.org/toolbox/examples/2002/xb/xbMarquee/examples/ch-js-loader.html

Other examples (which may not be working right now) and a full article:
Class xbMarquee
http://devedge-temp.mozilla.org/toolbox/examples/2002/xb/xbMarquee/index_en.html#Examples

The above 4 links are resources that should help the webmaster.

Expected results: to help/assist/have the webmaster modify the current code on ynet.co.il to make such DHTML scrolling news ticker more Firefox-friendly and more user system resources/cpu friendly.

Comment 1

[zohar]

Technical problems should go to: [e-mail] 

Comment 2

[Gérard Talbot]

Thank you zohar (David) for your quick response; I appreciate this. Today, I got a first reply from [e-mail] .

Comment 3

[Gérard Talbot]

I updated the URL to pinpoint the webpage where the DHTML code resides; it runs inside an iframe.

Comment 4

[Niro]

This problem has been reported as <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=142994">Bug 142994</a>

Comment 5

[Gérard Talbot]

Nir, please read again carefully both bugs. 
This bugreport here is about Tech Evangelism. Bug 142994 is about DHTML performance. The solution for ynet.co.il is known, working and available: it's all up to them to modify their script functions.

Comment 6

[Tsahi Asher]

(In reply to comment #5)
> Nir, please read again carefully both bugs. 
> This bugreport here is about Tech Evangelism. Bug 142994 is about DHTML
> performance. The solution for ynet.co.il is known, working and available: it's
> all up to them to modify their script functions.
> 

all of the bugs in comment 0 are duplicates of bug 142994 through bug 315444.

Comment 7

[Uri Bernstein]

IMO this bug is INVALID. The real Mozilla bug (142994) should be fixed.

Comment 8

[Gérard Talbot]

> IMO this bug is INVALID. The real Mozilla bug (142994) should be fixed.

Bug 322288 is not INVALID. I wrote to ynet.co.il to notify them of their DHTML-javascript marquee issue and offered them to assist them in adjusting their code by using what has been already working well, smoothly without detrimental effect (hogging) on user system resources for Firefox users.

Everything was nicely explained and written on January 3rd 2006 in an email clearly mentionning solutions (in the subject line and elsewhere) as following:

{
Gérard Talbot
נשלח: ד 04 ינואר 2006 04:22
אל: אינטרנט - כיתבו אלינו; YNET - Editor In Chief; אינטרנט - מערכת מחשבים
עותק: [e-mail]
נושא: ynet.co.il webpages caused very high CPU on non-IE browsers: solutions

Hello ynet.co.il,

My name is Gérard Talbot and I am a volunteer at Mozilla.org.

I wish to report to you that your website is popular among Firefox users and Mozilla
users. So far, at least 12 people in the last 12 months have reported problems on
your site in at least 9 bugzilla bugfiles due to the use of a DHTML scrolling news
ticker which uses a lot of cpu resources, system resources to activate the news
ticker, due in particular in the way this DHTML scrolling news ticker is coded.

Therefore, I have decided to open a tech evangelism bugfile at bugzilla.mozilla.org
on this particular issue.

Bug 322288:
ynet.co.il - High CPU usage caused by DHTML scrolling "marquee"-like news
ticker/message
https://bugzilla.mozilla.org/show_bug.cgi?id=322288

Unfortunately, I do not speak, nor write nor understand Hebreu. But I understand
DHTML and how to create/code a DHTML news ticker which will not over-use cpu or RAM
on a system.

I believe your webmaster can read the resources mentioned in bugfile
322288 and improve the webpages at ynet.co.il for the benefits of us all.

Mozilla browsers (Seamonkey and Firefox) are localized in Hebreu:
http://mozilla.org.il/

I have sent this email to contact, editor-in-chief and computers email addresses. I
had no idea to whom and how I could reach the ynet.co.il webmaster directly. So,
please forward this email to whomever would be in charge of such website issue.

Thank you for your understanding and please receive my best wishes for the new 2006
year,

Gérard Talbot
}

------

Subject:   	RE: ynet.co.il webpages caused very high CPU on non-IE browsers: solutions
From:   	&#1513;&#1512;&#1493;&#1514; &#1500;&#1511;&#1493;&#1495;&#1493;&#1514; YNET <[e-mail]>
Date:   	Wed, January 4, 2006 3:42 am
To:   	[e-mail]

Shalom from ynet,

Thank you for writing us.

Your comments were forwarded to our technical department.

We are always available for any question, problem or comment.
 
Best regards,

 
Rachel Said
Customer Service
http://www.ynet.co.il

------

Nir, Uri and others: a perfectly sensible solution (a W3C web standards compliant one, which will work for any/all W3C web standards compliant browsers) has been available for the last 4 years and is still available. As far as I'm concerned, it's all up to ynet.co.il   

Comment 9

[Gérard Talbot]

"Assigned to:" field now points to me.

Comment 10

[Uri Bernstein]

Ynet switched to a Flash ticker, instead of the old DHTML one. For me (on PPC Mac), the flash ticker still takes a significant proportion of the CPU cycles, but it's probably better than the older one.

IMO, it's a sad irony that Mozilla-induced "Tech Evangelism" is what apparently drove Ynet to move from an open, standard, technology (JavaScript), to a closed one (Flash).

Comment 11

[Tsahi Asher]

for me (SeaMonkey 1.0.4, WinXP) the home page of ynet takes 20%-40% cpu, but i can't tell if it's from the ticker or the loads of other flash ads they have there.

their ticker was also hijacked by many other sites that displayed it, this might also be a consideration to move to flash.

Comment 12

[Eyal Rozenberg]

This bug puzzles me. According to bug 142994, the reason why Ynet's ticker was causing high CPU usage was 'our' fault, not theirs. Trying to get JS recoded so as to make Mozilla bugs less visible is not something I believe we should be doing, certainly not as 'official' bugzilla-bug-motivated evangelism. The focus should have, in my view, been on fixing bug 142994, just as Uri suggested.

Regardless of this matter, since their ticker is now in flash, why is this bug still open? Suggest resolution as INVALID.

(In reply to comment #8)
> Bug 322288 is not INVALID. I wrote to ynet.co.il etc.

This sort of statement of position with no argument is not helpful. Plus, we should have agreed on whether it is invalid or not, before approaching Ynet. 

Comment 13

[Uri Bernstein]

Given Ynet's switch to Flash, I think we can drop the discussion on whether this bug is INVALID or not, and simply resolve it WORKSFORME - so that's what I'm doing.

Bug 142994 still has to be fixed, of course.

Comment 14

[Gérard Talbot]

(In reply to comment #12)
> This bug puzzles me. According to bug 142994, the reason why Ynet's ticker was
> causing high CPU usage was 'our' fault, not theirs. Trying to get JS recoded so
> as to make Mozilla bugs less visible 


This bug was about implementing a solution - a web standards, cross-browser one - which would have satisfied everyone involved as far as ynet.co.il webpages were involved: Gecko-based browser users, users with other browsers. It was also about implementing a forward-compatible solution since it was based on web standards. I have offered my assistance to ynet.co.il in the event they would have chosen to do such implementation.


> is not something I believe we should be
> doing, certainly not as 'official' bugzilla-bug-motivated evangelism. 

You believe the contrary. I believe it was judicious and correct to invite ynet.co.il to upgrade their code and to offer them assistance in their implementation. That is what the summary, the description and comment 8 were clearly and specifically saying. 
Upgrading ynet.co.il webpage code or not would have had no impact whatsoever on bug 142994. Upgrading ynet.co.il webpage code or not would not have prevented anyone from taking the assignment of bug 142994 and to fix it.

"We need help from people with experience in web development and quality assurance who can analyse sites and make recommendations to sites on how to upgrade their sites to support Mozilla."
http://www.mozilla.org/projects/tech-evangelism/

> The focus
> should have, in my view, been on fixing bug 142994, just as Uri suggested.

Just look at the assignee field in bug 142994: nobody is assigned to bug 142994.

If ynet.co.il had implemented a news ticker like in the already mentioned resources (it was easy to do!), then the pressure to fix bug 142994 would have been eased, at least for the ynet.co.il users.

> Regardless of this matter, since their ticker is now in flash, why is this bug
> still open? Suggest resolution as INVALID.
 
Flash is not necessarly more user resources friendly. Flash does not necessarly make a webpage more accessible either. Flash is proprietary, not web standards based. 
I still hoped ynet.co.il would have contacted me or examined the urls listed in the Description. The solution (based on the given examples) I was proposing was a better choice than Flash.

> (In reply to comment #8)
> > Bug 322288 is not INVALID. I wrote to ynet.co.il etc.
> 
> This sort of statement of position with no argument is not helpful. 

You snipped the part where the explanation is given as to why this bug is not INVALID. I have been repeating myself: bug 142994 was not specifically about ynet.co.il. There is such a thing as working with websites to help them upgrade their code for the better, you know.

Plus, we
> should have agreed on whether it is invalid or not, before approaching Ynet. 
> 

When you say "we", who are you talking about exactly?

Comment 15

[Eyal Rozenberg]

Great, we can start an argument, just the way I like it ;-)

(In reply to comment #14)
> This bug was about implementing a solution - a web standards, cross-browser one

Ynet's old ticker was AFAIK a standard JS cross-platform solution. The fact that it we have problems with it is due to a bug (or rather, performance issue) in Mozilla, not a problem with what Ynet had done wrong. Alternative ticker code would have prevented the issue from manifesting when people visit Ynet, that's true, but this would not have been 'helping the webmaster' - it would have been helping ourselves with a site-specific workaround for the issue.

> - which would have satisfied everyone involved as far as ynet.co.il webpages
> were involved: Gecko-based browser users, users with other browsers. It was
> also about implementing a forward-compatible solution since it was based on web
> standards. I have offered my assistance to ynet.co.il in the event they would
> have chosen to do such implementation.
 
If you find a crack in your house wall and you fill it up with cement and whitewash over it - is this a solution which "satisfies everyone involved"? Even if you're sure the house won't collapse I wouldn't think so. And again, AFAICT the performance issue we had was not due to erroneous or standard-breaking JS in Ynet's ticker.

> I believe it was judicious and correct to invite
> ynet.co.il to upgrade their code and to offer them assistance in their
> implementation. That is what the summary, the description and comment 8 were
> clearly and specifically saying.

Actually I also believe that, but not the way you did it, as a suggestion that their site needs to be upgraded somehow.
 
> Upgrading ynet.co.il webpage code or not would have had no impact whatsoever on
> bug 142994. Upgrading ynet.co.il webpage code or not would not have prevented
> anyone from taking the assignment of bug 142994 and to fix it.

Ah, you seem to posit the second sentence as an explanation of justification of the first, yet it isn't; as you yourself say later on...

> If ynet.co.il had implemented a news ticker like in the already mentioned
> resources (it was easy to do!), then the pressure to fix bug 142994 would have
> been eased, at least for the ynet.co.il users.

...right?


> "We need help from people with experience in web development and quality
> assurance who can analyse sites and make recommendations to sites on how to
> upgrade their sites to support Mozilla."
> http://www.mozilla.org/projects/tech-evangelism/

I would think the use of 'upgrade' in this context refers to a change from MSIE-specific site design and JS coding to standards-compliant design and coding, not the use of workarounds for Mozilla bugs which MSIE does not exhibit. Otherwise, you should be asking me to 'upgrade' my own homepage to use table hacks for positioning content since Mozilla doesn't support position: relative and position: fixed properly.

> > The focus
> > should have, in my view, been on fixing bug 142994, just as Uri suggested.
> 
> Just look at the assignee field in bug 142994: nobody is assigned to bug
> 142994.

Exactly... that is the problem we should try to solve (and not only in the context of this specific issue. Just look at the seemingly trivial bug 14871 for example).


> > still open? Suggest resolution as INVALID.
> 
> Flash is not necessarly more user resources friendly. Flash does not necessarly
> make a webpage more accessible either. Flash is proprietary, not web standards
> based. 

It's not 'non-standard', it's just a proprietary standard. But let's not split hairs, I agree that using Flash is not such a good solution for a news ticker. But now this is without a doubt outside of the scope of Mozilla evangelism, now it's just a campaign to promote website resource frugality. This is again IMHO INVALID.

> Plus, we
> > should have agreed on whether it is invalid or not, before approaching Ynet. 
> 
> When you say "we", who are you talking about exactly?
> 

Oh, I mean people active in Mozilla QA and/or evangelism and/or development work which relates to Ynet.co.il and/or the ticker performance issue. But I'm not very important in this respect so you can s/we/you if you like.

Comment 16

[Gérard Talbot]

(In reply to comment #15)

> Ynet's old ticker was AFAIK a standard JS cross-platform solution. 

It was based on quirks mode, not standards compliant rendering mode for starters.
From function Tck_Roll():
	a.style.top = parseInt(a.style.top)-1
	b.style.top = parseInt(b.style.top)-1

From function Tck_Init():
	a.style.top = 130;
	b.style.top = a.offsetHeight +130;

Notice the missing unit in the above 4 instructions: CSS parsing errors are enforced in standards compliant rendering mode.

The fact
> that it we have problems with it is due to a bug (or rather, performance issue)
> in Mozilla, not a problem with what Ynet had done wrong. Alternative ticker
> code would have prevented the issue from manifesting when people visit Ynet,
> that's true, 

The solution I was proposing to ynet.co.il would have worked for Gecko-based browsers users and for other browser users: that is what I'm saying (also in comment #14) and the links, examples, etc.. listed in comment #0 demonstrated this beyond any reasonable doubt.

> but this would not have been 'helping the webmaster' - it would
> have been helping ourselves with a site-specific workaround for the issue.


Not just "ourselves". But others using browsers like MSIE 7, Opera 9, Safari 2.x, etc.. 
Not just ynet.co.il site. Any site with a stock ticker, news ticker, DHTML-marquee, etc. can implement it with and thanks to the resources given in comment #0. That's why B. Clary and D. Rosenberg created those files back in August 2001 to begin with.

> > - which would have satisfied everyone involved as far as ynet.co.il webpages
> > were involved: Gecko-based browser users, users with other browsers. It was
> > also about implementing a forward-compatible solution since it was based on web
> > standards. I have offered my assistance to ynet.co.il in the event they would
> > have chosen to do such implementation.
> 
> If you find a crack in your house wall and you fill it up with cement and
> whitewash over it - is this a solution which "satisfies everyone involved"?
> Even if you're sure the house won't collapse I wouldn't think so. And again,
> AFAICT the performance issue we had was not due to erroneous or
> standard-breaking JS in Ynet's ticker.
 

I already said that "fixing" bug 322288 was not going to impact on bug 142994: those 2 bugs are not the same (I already explained that). You can avoid problem A by using solution B (bug 322288), not just by using (or waiting for) solution A (bug 142994). You can avoid cracks in your house by fixing the house foundation: that is what bug 322288 is about.
You can verify the referenced resources in comment #0 in 5 years from now and I'm absolutely convinced they will still work accordingly, as expected without hogging cpu/RAM.


> > I believe it was judicious and correct to invite
> > ynet.co.il to upgrade their code and to offer them assistance in their
> > implementation. That is what the summary, the description and comment 8 were
> > clearly and specifically saying.
> 
> Actually I also believe that, but not the way you did it, as a suggestion that
> their site needs to be upgraded somehow.

I still think ynet.co.il code could be improved for the benefits of everyone involved.

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.ynet.co.il%2Fhome%2F0%2C7340%2CL-8%2C00.html
662 validation markup errors; No doctype declaration

http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fwww.ynet.co.il%2Fhome%2F0%2C7340%2CL-8%2C00.html&usermedium=all
193 CSS errors with dozens and dozens of warnings.

> > Upgrading ynet.co.il webpage code or not would have had no impact whatsoever on
> > bug 142994. Upgrading ynet.co.il webpage code or not would not have prevented
> > anyone from taking the assignment of bug 142994 and to fix it.
> 
> Ah, you seem to posit the second sentence as an explanation of justification of
> the first, yet it isn't; as you yourself say later on...


Eyal, I have tried to propose a constructive (a fully web standards compliant one and a more user-resources friendly one) solution for all parties involved and for the better. A forward-compatible solution. A future-proof one. Since I created bug 322288, I have for the most part received negative feedbacks, complaints from people like you, comments that this bug was invalid, futile, not helpful, missing the point, etc.. I spent time, energy in bug 142994 and here into trying something here. Concretely speaking, the only thing you have suggested is to resolve this bug as INVALID.

> > If ynet.co.il had implemented a news ticker like in the already mentioned
> > resources (it was easy to do!), then the pressure to fix bug 142994 would have
> > been eased, at least for the ynet.co.il users.
> 
> ...right?
 

When 12 people reported 9 duplicate bugs of bug 142994 - all of them pointing specifically and explicitly to ynet.co.il -, then it's clear that there is sufficient justification to contact the website responsibles and to notify them about a perfectly valid and constructive solution for all parties involved. You and all the others saying this bug is a DUPLICATE or is INVALID or is not helpful never quite understood that from the start.


> > "We need help from people with experience in web development and quality
> > assurance who can analyse sites and make recommendations to sites on how to
> > upgrade their sites to support Mozilla."
> > http://www.mozilla.org/projects/tech-evangelism/
> 
> I would think the use of 'upgrade' in this context refers to a change from
> MSIE-specific site design and JS coding to standards-compliant design and
> coding, not the use of workarounds for Mozilla bugs which MSIE does not
> exhibit. Otherwise, you should be asking me to 'upgrade' my own homepage to use
> table hacks for positioning content since Mozilla doesn't support position:
> relative and position: fixed properly.


You misunderstand the nature of the proposed change. The solution proposed was more efficient DHTML-driven code, not of a different nature. Anyone familiar with Javascript, DHTML, CSS can examine the linked resources in comment #0 for himself.
Tech Evangelism is about upgrading webpage code so that it can work well (accordingly and as expected) in any web standards compliant browsers to begin with.

> > > The focus
> > > should have, in my view, been on fixing bug 142994, just as Uri suggested.
> > 
> > Just look at the assignee field in bug 142994: nobody is assigned to bug
> > 142994.
> 
> Exactly... that is the problem we should try to solve (and not only in the
> context of this specific issue.

I was proposing a standard compliant solution. When no one is about to fix bug 142994, what better was there to do? 

It's very easy for people like you to demand that others fix bug 142994 .. but until that can be done (and this will NOT be easy to achieve), what else are you proposing?

> 
> > > still open? Suggest resolution as INVALID.
> > 
> > Flash is not necessarly more user resources friendly. Flash does not necessarly
> > make a webpage more accessible either.
> 
> It's not 'non-standard', it's just a proprietary standard. But let's not split
> hairs, I agree that using Flash is not such a good solution for a news ticker.

Flash is not more accessible, user-friendly and Flash is not more user-resources friendly.

> But now this is without a doubt outside of the scope of Mozilla evangelism, now
> it's just a campaign to promote website resource frugality. This is again IMHO
> INVALID.

Too much animation (regardless of code involved/used) will peg the cpu/video card/RAM. 
E.g: Try this with any version of MSIE
http://www.dokimos.org/ajff/
Too much demanding animation with setInterval, setTimeout (especially where the delay is shorter than 64ms) will affect cpu/RAM and will make the application slow, unresponsive, will sometimes crash the application: that's true for any browser and that's true regardless of quality of code per se.
Over-declaring, over-defining, over-coding (CSS code, markup code, tables, js), over-linking, etc have been seen in webpages too and they do bring consequences, side effects.

Comment 17

[Eyal Rozenberg]

(In reply to comment #16)
> It was based on quirks mode, not standards compliant rendering mode for
> starters.

Ok, you're technically right, but this is not the reason Mozilla has trouble with it; there wasn't anything essentially counter-standard about it (e.g. using some capability of IE only, or ActiveX voodoo, or whatever).

> 
> Not just "ourselves". But others using browsers like MSIE 7, Opera 9, Safari
> 2.x, etc.. 

Why, did any of those have problems with the ticker?

> A (bug 142994). You can avoid cracks in your house by fixing the house
> foundation: that is what bug 322288 is about.

No, fixing the foundation is fixing bug 142994, that's my whole point.

> I still think ynet.co.il code could be improved for the benefits of everyone
> involved.
> 
> Eyal, I have tried to propose a constructive (a fully web standards compliant
> one and a more user-resources friendly one) solution for all parties involved
> and for the better.

> etc.

I'm all Ynet using a decent ticker like you suggested, what I don't agree with is your trying to promote that under the title of 'upgrading their site to support Mozilla' or 'helping' the webmaster. They way I think you could have handled it is write them that unfortunately, their ticker triggers a performance problem in Mozilla, and would they be considerate enough to change the ticker to avoid this, and that you can suggest more standards-compliant options which are likely to perform better.

Of course, in your place, I would rather get people annoyed about the Ynet issue to pester the developers about fixing bug 142994, or getting some new volunteer to do it, if it's at all possible.