Closed Bug 161109 Opened 22 years ago Closed 2 years ago

non-animated mode pref (disabling marquee, t-d:blink, anim gifs, mngs)

Categories

(Core :: CSS Parsing and Computation, defect, P3)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: bugzilla_kl, Unassigned)

References

Details

(Keywords: access, helpwanted, testcase, Whiteboard: [wgate])

Attachments

(1 file, 4 obsolete files)

Testcase
584 bytes, text/html
Details 
the (proprietary) HTML-Tags <blink> and <marquee> can be very boring for users -
we should add an option (in the GUI) to disable the effects themself (the
-moz-binding on <marquee> and the text-decoration:blink; on <blink>)
gar.. ! "Prefeerenced" should be renamed to "Preferences Window"...
Assignee: ben → attinasi
Status: UNCONFIRMED → NEW
Component: Preferences → Layout
Ever confirmed: true
QA Contact: sairuh → petersen
Yes, I shouldn't have to use the Zap cheap effects bookmarklet every time I run
in to a page containing that garbage...
UI pref for blink -> bug 106462
i want to cut off those little bastard <blink>'s and <marquee>'s heads ;)
Summary: add an option to disable DHTML-Tags → add pref for disabling annoying non-standard HTML elements ("DHTML Tags")
Priority: -- → P3
This can go two routes-it can become a meta bug for bug 106462 and there can be
a new bug for a marquee pref (bug 161049 is for REMOVING marquee) or this can
become the bug to remove marquee.
Keywords: helpwanted
stylesheet for the "don't go on users nerves" bug for marquee:

marquee{
	-moz-binding:none;
	overflow:auto;
	display:block;
}

the display:block; is another bug waiting for checkin - and so required to test
on the current code.
doron, how do you get the height for vertical marquee? I guess we still need
that for this mode.
Attached patch implementation of marquee pref (obsolete) — — Splinter Review 
This patch implements a pref, "browser.display.enable_marquee", and sets the
default to false.
Comment on attachment 95581 [details] [diff] [review]
implementation of marquee pref

Note that this patch does not have UI for the pref.  Rather, it's a hidden pref
that distributors could set.
David: I guess, that this should find friends everywhere...
Comment on attachment 95581 [details] [diff] [review]
implementation of marquee pref

I should remove the |aMedium| checks -- those were from when I was writing the
patch to work the other way around.
This should have "sec508" keyword because it blocks Section 508 requirement:

   (h) When animation is displayed, the information shall be displayable in at
   least one non-animated presentation mode at the option of the user.

I would add it myself, but I can't because someone decided to play games with my
privs.
Adding access and sec508 keywords.
Keywords: access, sec508
Taking bug.  I'll try to get this in for 1.1a...
Assignee: attinasi → dbaron
Component: Layout → Style System
Priority: P3 → P2
QA Contact: petersen → ian
Whiteboard: [patch]
Target Milestone: --- → mozilla1.2alpha
Attached patch revised patch (obsolete) — — Splinter Review 

        Attachment #95581 -
        Attachment is obsolete: true

    
    

    
  
Why not do the pref checking in the xbl?

    
    

    
  
dbaron's patch(attachment 96164 [details] [diff] [review]) can't be applied for 1.1
on my Linux. Compiler can't find nsIPref.h.

    
    

    
  
What is the likelihood of this being put in the 1.0.x branch? Since the
<marquee> tag has slithered into there, the ability to switch the vile
thing off should be put in as well.

    
    

    
  
As I have mentioned in other bugs, if there is a UI pref for this, it should be
the same UI pref which disabled blink and animated GIFs and other things that
make for a "non-animated presentation mode". Please, don't add a gazillion prefs
for each of the various ways of animating text.

    
    

    
  
I have hacked xbl-marquee.xml to provide scrollbar instead of automatic
scrolling. This is only a "hack", but you can use it just now to disable
annoying behavior of <marquee>.

It would be nice to add user pref for this, e.g.
user_pref("browser.marquee.behavior", "autoscroll" | "block" | "scrollbars" );

Please, test it. For details see
http://bugzilla.mozilla.org/show_bug.cgi?id=163048#c5

    
    

    
  
> dbaron's patch(attachment 96164 [details] [diff] [review]) can't be applied for 1.1
> on my Linux. Compiler can't find nsIPref.h.

That's because the patch for bug 71257 changed the REQUIRES line in the
relevant Makefile.in.

    
    

    
  
nsIPref.idl says:

 47 /*
 48  * This entire interface is deprecated and should not be used.
 49  * See nsIPrefService and nsIPrefBranch for the new implementations.
 50  */

I strongly second that sentiment... Please switch to nsIPrefService.  Though
that _does_ force you to implement nsIObserver instead of just using a static
callback...

+    if (aRuleData->mDisplayData->mDisplay.GetUnit() == eCSSUnit_Null)
+      aRuleData->mDisplayData->mBinding = nsCSSValue(eCSSUnit_None);

Shouldn't you be checking mBinding's unit?

+  tag = getter_AddRefs(NS_NewAtom("MarqueeDisableRule"));

I always get confused when I see this usage of getter_AddRefs... maybe use
dont_AddRef?  Either way, though.

+PR_STATIC_CALLBACK(int)

PRInt32?

You don't seem to release mMarqueeDisableRule anywhere...  is there really a
reason not to have that be an nsCOMPtr<nsIStyleRule> ?

Changing the pref won't dynamically restyle the documents that are already
loaded, right?  Is that what we want?

Comment 19 does not apply to this bug so far, since this is all back end, no UI.
 I agree that there should only be one front-end checkbox, but separate back-end
prefs (the checkbox will toggle multiple prefs at once).  That gives embeddors
the flexibility to ship whatever UI and default settings they want.

    
    

    
  
Can I read user prefs within XBL method? If yes, we could choose desirable
behavior of <marquee> directly in xbl-marquee.xml.

    
  
Blocks: 106462, 163048

    
    

    
  
you should beable to check prefs from xbl

    
    

    
  
Doron, unfortunately attempt to access prefs in XBL causes exception
"enablePrivilege not granted".

See bug 163048 comment 8 for more details. I'll be indebted to you for any
suggestions.

    
  
Blocks: advocacybugs

    
    

    
  

      
      
      
      

        Attached file
          
        Testcase
        — 
      

    


  

    
    

    
  
Jacek, I has tested your testcase on my XBL which provide scrollbar for
<marquee> instead of autoscroll (see bug 163048).

Because of this emerges a question: my XBL generates a horizontal scrollbar
although width of marquee area is <= than width if container; so scrollbar is
unusable. On the other hand, nevertheless, this scrollbar signifies that
<marquee> tag is present at HTML code, this might be helpful for some users.

I would ask participants of discussion, which alternative should be better in
this case.

    
    

    
  
Just give me a UI and a pref to turn off BLINK and MARQUEE.  Both.
Target Milestone: mozilla1.2alpha → mozilla1.2beta

    
  
Keywords: testcase

    
    

    
  
Comment on attachment 102724 [details] [diff] [review]
revised patch for backend of marquee pref

> +  nsCOMPtr<nsIAtom> tag;
> +  tag = getter_AddRefs(NS_NewAtom("MarqueeDisableRule"));

do_GetAtom, perhaps?

> +MarqueePrefObserver::MarqueePrefObserver() { NS_INIT_ISUPPORTS(); }

Add an assertion that gHaveMarqueePref is null?

r/sr=bzbarsky with that.

        Attachment #102724 -
        Flags: superreview+

    
    

    
  


  
Revised per bzbarsky's comments.  I made the atom change in a number of other
places where the same pattern occurs.

        Attachment #102724 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 102728 [details] [diff] [review]
patch for backend of marquee pref

Transferring sr.

        Attachment #102728 -
        Flags: superreview+

    
    

    
  
Comment on attachment 102728 [details] [diff] [review]
patch for backend of marquee pref

>Index: modules/libpref/src/init/all.js
>===================================================================
>+pref("browser.display.enable_marquee",      false);

Cool :)  After all the debate though in the original "support marquee" bug,
please make sure that distributors know about this.  A release note may be a
good idea.


>Index: content/html/style/src/nsHTMLStyleSheet.cpp
>===================================================================
> nsresult
> HTMLStyleSheetImpl::Init()
> {
>+  if (!gHaveMarqueePref) {
>+    gHaveMarqueePref = PR_TRUE;

Don't you want to wait on setting gHaveMarqueePref until after we know we can
get the pref?

>+    nsresult rv;
>+    nsCOMPtr<nsIPrefService> prefService = do_GetService(kPrefServiceCID, &rv);
>+    if (NS_SUCCEEDED(rv)) {
>+      nsCOMPtr<nsIPrefBranch> branch;
>+      rv = prefService->GetBranch(kMarqueePrefBranch, getter_AddRefs(branch));
>+      if (NS_SUCCEEDED(rv) && branch) {
>+        branch->GetBoolPref(kMarqueePrefName, &gEnableMarquee);
>+        nsCOMPtr<nsIPrefBranchInternal> branchInternal
>+            = do_QueryInterface(branch);
>+        if (branchInternal) {
>+          nsCOMPtr<nsIObserver> observer = new MarqueePrefObserver();
>+          if (observer) {
>+            branchInternal->AddObserver(kMarqueePrefName, observer, PR_FALSE);
>+          }
>+        }
>+      }
>+    }
>+  }


r=caillon otherwise.

        Attachment #102728 -
        Flags: review+

    
    

    
  
I am planning to announce this to the API-changes list.  The reason I set
gHaveMarqueePref early was that if we are for some reason running in a pref-less
installation or one where prefs are broken in some way, we don't go to the
service manager every single time.

    
    

    
  
Ah.  Makes sense.  Wanna comment that?

    
    

    
  
I added the comment in my tree:

    // Set |gHaveMarqueePref| now, so we don't recheck if something fails.


    
    

    
  
Doron, BobJ:  Is this OK with you?  The patch makes a marquee pref that's
disabled by default, so anyone who wants to distribute a marquee-enabled Mozilla
would need to add

pref("browser.display.enable_marquee", true);

to their default preferences.


    
    

    
  
fine with me, we can turn on the pref for commercial.

    
    

    
  
Nice, but I would see 3 choices for marquee behavior: autoscroll, block and
scrollbars. Cite from bug 163048:

AFAIK <marquee> support was introduced mainly for Chinese users - see test pages at:
http://bugzilla.mozilla.org/show_bug.cgi?id=156979#c63

And if we'll parse <marquee> just as <div>, appearance of these pages will be
violently distorted. <marquee> has attributes WIDTH and HEIGHT, parsing as
simple <div> causes incorrect rendering width and height of <marquee> block and,
therefore, destroying page layout.

I tried to find method for displaying <marquee> which doesn't destroy appearance
and preserve usability.

But literally following W3C standards, we must render <marquee> as unknown tag,
i.e. simple ignore it and render even not as <div>, but as <span>.

As a result we have 4 alternatives to render <marquee>:
1. As inline element (conforms to standard, but completelly destroies page layout);
2. As <div> (better corresponds meaning of this tag, but causes layout problems);
3. With autoscrolling (exactly as MS Internet Explorer, preserves page layout,
but annoies users and causes usability problems);
4. With scrollbar (preserves page layout, saves usability and doesn't annoy).

I think, all 4 alternatives could be embodied in preferences, but it seems to me
that scrollbar might be a better choice.

Draft XBL for scrollbar emulation of marquee is available at:
http://bugzilla.mozilla.org/attachment.cgi?id=97516&action=view

    
    

    
  
one question - will this break people who use a external xbl file for <marquee>?
 That is valid...

    
    

    
  
No, it  should only override user or ua level styles.  (I haven't actually
tested, though.  Do you have a testcase?)

    
    

    
  
Is the ability to disable <marquee> by editing userContent.css,
insufficient?  The lines needed are already there as comments which
a user or distributor, could easily un-comment.  See
http://lxr.mozilla.org/seamonkey/source/profile/defaults/chrome/userContent-example.css
 25 /*
 26  * example: turn off "marquee" element
 27  *
 28  * marquee { -moz-binding: none; }
 29  *
 30  */

If this is done, I believe mozilla will resort to the old behavior
and treat the unknown marquee tag as a <div>.  We could default
it the other direction for mozilla and change it for commercial.

However, see previous comments about layout problems associated
with treating marquee as a div.  I like the scrollbar suggestion
that would preserve the page layout.

For whatever we do, make sure our testcases include both
horizontal and vertical marquees.

    
    

    
  
Bob, in theory that would work, but it doesn't because of the way XBL works. 
Once you load a binding, there is no way to unload it currently.  See bug 119078
and bug 163023 which look like dupes of each other.

    
    

    
  
a=rjesup@wgate.com for trunk checkin.  We at Wgate want this too.

Added 119078 and 163023 as dependencies, since I think the -moz-binding: none
solution would be preferable to a pref (unless we wanted to go for a fancier
solution with multiple ways to handle <marquee>).
Depends on: 119078, 163023
Whiteboard: [patch] → [patch][wgate]

    
    

    
  
http://bugscape.mcom.com/show_bug.cgi?id=20559 filed to track this for embedding

    
    

    
  
is it possible to set this userContent.css stuff over UI?

    
    

    
  
Comment on attachment 102728 [details] [diff] [review]
patch for backend of marquee pref

Fix checked in to trunk, 2002-10-14 17:06/07 PDT.

Leaving bug open for other work.

        Attachment #102728 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 102728 [details] [diff] [review]
patch for backend of marquee pref

I've changed my mind about this, and decided that I want to back this out.  See
my comments in bug 156979 comment 30.

    
    

    
  
David, do you agree that scrollbar might be reasonable compromise?

    
    

    
  
David: If you won't cooperate and rid us of the evil marquee, someone will
eventually back out your backout. :)

This bug is not an issue of compatibility, it's an accessibility issue. We're
violating section 508 requirements as well as numerous other accessibility
documents. I can't understand why the <MARQUEE> tag means more to you than that.

    
    

    
  
The section 508 requirement in question can't be enforced for pages using the
DOM and JavaScript, so I don't see why it's relevant to MARQUEE.  In fact, I
don't see any reason MARQUEE is any worse for accessibility than the ability to
use script on web pages.  In fact, it's probably not as bad since it can be
styled in userContent.css.

    
    

    
  
As I said over a month ago, the UI for this pref should be the same UI which 
disables blink and animated GIFs and other things that make for a "non-animated 
presentation mode". That's what's needed for the sec508 problem.

    
    

    
  
Incidentally, a=asa r=hixie on the backout to re-enable <marquee> on the trunk.

    
    

    
  
I'm really disappointed. IMHO, the only sense for supporting marquee is
preservation of page layout, because usually marquee are advertizing text which
only annoies and distract user from useful content on page.

Support of marquee as prolate MSIE extension is certainly attractive challenge
for Mozilla hackers and I'm amazing this accurate XBL emulation.

But we make our browser not only for our delight, but for end users. I consider
that scrollbar emulates marquee by more user-friendly method, and I would hear
serious arguments for autoscrolling against scrollbar.

    
    

    
  
Autoscrolling:  Perfect MSIE emulation.  Great for ad companies.
Scrollbar:  Better for readability via many screen readers for blind, etc...
Disble:  Less annoyance, period.

Make everyone happy.  Just put it in as a tri-state pref and tell me what the
pref is.  

    
    

    
  
Wasn't the idea to have one front-end checkbox (as Hixie said in comment 52)
that would set the seperate backend prefs for marquee, blink and all those other
annoyances?
Why would that require backing out this pref? Or if all these annoyances really
should be controlled by one pref, could we at least wait with removing _this_
one until someone has created that unified pref?

    
    

    
  
I agree with Hixie, a general accessibility should turn off marquee.

    
    

    
  
I would like to clarify that this bug is *not* for discussing marquee, *nor* for
discussing how to make marquee look prettier.

This bug is there for accessibility and usability reasons. The enhancement to be
worked on in this bug is supposed to be a GUI pref called something like "Ignore
annoying HTML elements" and should change the behaviour of tags such as
<marquee> or <blink> *at once*.

    
    

    
  
>The section 508 requirement in question can't be enforced for pages using the
>DOM and JavaScript, so I don't see why it's relevant to MARQUEE.

Yes, it can. If a user encounters a page with JavaScript animations they can
turn it off in Preferences. We need the same accessibility for marquee.

Even if you *do* think that for some reason Mozilla has an obligation to those
flickering Chinese sites that [mis]use marquees, there's absolutely no reason we
can't at least have access to a pref to turn it off! Especially since the code
already exists (a simple change to all.js would make it be enabled by default)!
And when there are accessibility documents that *mandate* that there be a way to
turn animations off, there really is no excuse for you to be backing out this pref.

No longer can you say "if you want it so bad, write a patch" because the patch
already exists, and you created it yourself! Now you're backing it out like a
fool. I suggest you think about what you're doing here.

    
    

    
  
Part of the reason I want to back the patch out is that it's too much code for
such a simple pref, and I don't like the design of it.  I'd rather see this pref
be part of a larger architecture for a auto-written user-stylesheet.

That said, we do provide a way to disable marquee.  You can edit
userContent.css.  That will do anything that this pref does.

    
    

    
  
(Why did I write a patch I didn't like?  Because I felt under pressure from
people who were threatening to quit in order to get their way.  That's a bad
precedent to set, and that's why I want to back the patch out entirely.)

    
    

    
  
> That said, we do provide a way to disable marquee.  You can edit userContent.css.

David, can you provide a rule that actually works then?

  marquee { -moz-binding: none }

does not, as I pointed out in comment 43.

    
    

    
  
  marquee { -moz-binding: none }

...really _should_ work, if it doesn't then we have an error in the cascade.
That doesn't remove the binding, it should prevent the binding from being set in
the first place.

If it really doesn't work please file a bug.

    
    

    
  
I think, the best choice might be reading user prefs directly in XBL, see
comment 23. This could spare us C++ code for this pref (David, is it what you
want?) and add flexibility for further similar issues (for example, to turn off
<blink> via XBL).

But unfortunately XBL is executing in current page context and can't read user
prefs (comment 25). Can we allow chrome XBLs (not XBLs from Web page, of course)
to read prefs? And what we must do for it?

    
    

    
  
Re comment 62: I just added the rule:

marquee { -moz-binding: none; }

to my userContent.css and marquees stopped animating.  I have no idea where this
myth about -moz-binding came from, but it's determined by the cascade just like
any other property.

    
    

    
  
When was marquee originally checked in? After 1.1? We should mention the
-moz-binding CSS to disable it in the release notes if we're going to mention
the addition of support for an IE extention (and an annoying one at that).

Is marquee disabled in Strict?

    
    

    
  
David, I have read your explanation, but I can't agree with your reasons.

> Having forks in the code hurts testing and development.
Yes, 100% yes. But editing userContent.css to disable marquee is wrong method as
compared with preferences GUI. Reasonable solution might be reading user prefs
directly in XBL.

>Having an implementation of marquee improves our compatibility with the web,
>and we are a web browser.
Maybe, maybe...
But does this mean that we must support _all_ MSIE extensions _exactly_ as MSIE?
We don't support <bgsound> (one of favorite backdoor for e-mail viruses in
Outlook), VBscript or ActiveX - and must we support it in future?

I can't see any advantage for autoscrolling against scrollbar (for example).
Marquee in 99% cases is being used for advertizing - and the fact that you
prefer the most annoying implementation for marquee denotes that you more like
ad companies than end users.

>Much of the opposition to marquee is related to marquee being
>nonstandard, yet few people have objected to the many nonstandard
>things we do because Netscape 4.x, and in some cases also MSIE for
>Windows, do them.  Nor do people object to all the tiny details of
>layout that we imitate despite that they are not described in any
>standard
I don't argue, MSIE have some non-standart, but very useful extensions, such as
innerHTML and offsetWidth properties or transformNode method.

But marquee isn't useful for webserfers. Layout problems can be solved with
scrollbar. Another problems? I don't see it, maybe, you do?

>From an accessibility perspective, marquee is not nearly as bad
>as the equivalent script
Yes, but I always can turn off annoying scripts via prefs - both wholesale (all
JS) and by retail (pop-ups, reading cookies, substitution of status bar etc.).
But thanks to your diligence we lose pref for marquee.

Summing up: you tell reasonable things. But in this case your arguments miss
beside the mark.

My propositions:
1. Allow reading user prefs from chrome XBLs. I don't know how to do it, but, I
hope, this isn't a hard work. I have opened bug 177660 for this issue.

2. Create XBL for marquee with tree alternates (block, scrollbar, autoscroll).
with scrollbar as default. If reading user prefs within XBLs will be allowed, I
engage myself to write this XBL soon.
Depends on: 177660

    
    

    
  
Related: Bug 159704 (some fixes for marquee)

    
    

    
  
> Reasonable solution might be reading user prefs directly in XBL.

That adds extra bloat and performance loss to our XBL loading just for this
trifle of all tags that is used highly infrequently.  If you mean from with the
XBL content as opposed to the backend, then you are still incurring a
performance hit as opposed to the userContent.css method, because you have
already paid the cost for the binding at that point.

> does this mean that we must support _all_ MSIE extensions _exactly_ as MSIE?

No.  We don't even support marquee exactly as MSIE does.  We support it
partially, so that 99% of the sites that use marquee work.  To get the other 1%
to work, we would have to do an insane amount of work, which is not feasible. 
We support this because it was easy to support what we did, and because there
are sites that require it.  Go look at some of the other bugs where Bob Clary
posted the links to sites that need this.

> Marquee in 99% cases is being used for advertizing

Marquee in 99% of cases isn't even used.  I find it hard to believe that this
annoys this many users as often as wolf is being cried.  What I do when I visit
sites that annoy me is *gasp* stop visiting them.

> I always can turn off annoying scripts via prefs

You totally missed the point.  If you force authors to write JS, then their
content is in (generally) the JS:

  |var textToShow = "Sniper Caught!  Rifle Found in Car is Tied to Killings";|

If you disable JS, you lose that content completely and have no idea that the
sniper is caught.  However if you just disable the binding, you still are able
to see the content, and access its linked text if there is a link embodying it.

    
    

    
  
>That adds extra bloat and performance loss to our XBL loading just for
>this trifle of all tags that is used highly infrequently.
Almost 2 month ago I wrote a draft XBL to provide three alternates. Its size was
14K against 11K of original XBL. Is this a bloat?

Perfomance loss isn't a problem because execution time would be increased only
by time to switch statement - code for another choices isn't being executed
anyway. More serious problem is performance loss during autoscrolling - and
ability to turn off marquee or scrollbar emulation of it saves this time.

>We support this because it was easy to support what we did,
>and because there are sites that require it
Your arguments against scrollbar emulation?

>However if you just disable the binding, you still are able
>to see the content, and access its linked text if there is
>a link embodying it.
Why I must edit some files in my profile manually to tune up my browser? What is
an conceptual reason to deny turn off marquee via preferences dialog?

    
    

    
  
>I can't see any advantage for autoscrolling against scrollbar (for example).
>Marquee in 99% cases is being used for advertizing - and the fact that you
>prefer the most annoying implementation for marquee denotes that you more like
>ad companies than end users.

We support JavaScript and Image, which are mostly used for ads.  So should we
turn those off too?

Get real, how many here have encountered a site using marquee in daily
websurfing? I haven't and I wrote the original impl. 

You who hate marquee should be happy we implement it - this will make sites go
from hacked up javascript/flash/java tickers to <marquee>, and then you can
disable them all at once with some css changes.

    
    

    
  
>We support JavaScript and Image, which are mostly used for ads.
>So should we turn those off too?
We have very flexible prefs to control JS and images which allow turn off
annoying ones without affect to necessary scripts/images.

And we haven't any prefs to control marquee without profile hacking. Is it correct?

>Get real, how many here have encountered a site using marquee
>in daily websurfing?
Alas yes, practically daily. Furthermore, webmasters get to know that marquee
now works in Gecko browsers and this evil extends more and more.

Fortunately I use my own XBL which provides scrollbar ;))) and I want users to
be enabled choose desired behavior: I consider they to have this right firmly.

>I haven't and I wrote the original impl.
Great work, really. I'm not programmer, only webmaster and I'm amazing. If bug
177660 will be fixed, I shall consider for honour to bring the modest
contribution to your work.

Another argument in favour of scrollbar: autoscrolling causes usability problems
even if you like content of marquee.

Assuming that you see page with marquee. Two troubles are possible.

First case: text or link that would interest you, is placed far in the tail. You
must wait a long time to see it - and probably you simply willn't wait until it
will appear on screen and therefore you willn't notice it.

Second case: interesting link appears in first place, you notice it, but while
you read remaining content at page, the link is crept away. And agonizing
suspense again...

Scrollbar easily solves both problems, gives instant access to any passage in
marquee and doesn't annoy. And it saves main advantage of marquee - preserves
page layout. I use scrollbar XBL about 2 months and to me never there came an
idea to return to an autoscrolling. Simple test it - and I hope, you will agree
with me.

Finally - let user to choose how he want to see marquee. Let not consider, that
we it is cleverer than him.

    
    

    
  
Doron, disabling marquee with some css changes is only feasible for the elite
few.  If Mozilla is to continue to expand market share, we must not frustrate
our userbase with a feature that a significant percentage feel negative about,
unless we give them a way to disable that feature within the realm of their
understanding and ability. Adding a marquee to a site using the marquee tag is a
lot easier than doing so with JavaScript or Flash. The importance of this bug
will only grow over time. The bottom line is, we need a pref with UI for
disabling marquee. 

Leaving marquee on as a default is not a problem, as long as there is UI
available to turn it off.
Whiteboard: [patch][wgate] → [wgate]

    
    

    
  
>Doron, disabling marquee with some css changes is only feasible for the elite
>few.  If Mozilla is to continue to expand market share, we must not frustrate
>our userbase with a feature that a significant percentage feel negative about,
>unless we give them a way to disable that feature within the realm of their
>understanding and ability.

So Internet Explorer, which has marquee, owns the market.  I fail to see why
people would not move to mozilla because of marquee.  I see no diemarquee.org
movement trying to get rid of it in IE.

If there is a pref that would help accessible users (not sure how they are
actually called), and if that pref by chance also gets rid of annoyances, then
that sounds fine.  Just targetting marquee is plain childish, our market share
increased a bit even during the period we added it.

If you really want to make the browser better, then create one pref that rules
them all, not one pref for each minor kingdom that wants something...

    
    

    
  
Why do I feel like I am repeating myself. This pref's UI should be the same UI 
which disables blink and animated GIFs and other things that make for a 
"non-animated presentation mode". That's what's needed for the sec508 problem.
Summary: add pref for disabling annoying non-standard HTML elements ("DHTML Tags") → non-animated mode pref (disabling marquee, t-d:blink, anim gifs, mngs)

    
    

    
  
I can't agree with global "non-animated" pref. Animated gifs (and particularly
MNGs) often contain essential information. I use animated gifs occasionally, for
example, I have used it to demonstrate new design of combustion engine. If user
will turn off animation, he willn't see how this engine works. Of course, I
could use AVI or Java applet in this case, but animated gif appears as the most
compact and compatible solution.

But marquee animation doesn't contain additional information besides it content.

>So Internet Explorer, which has marquee, owns the market.  I fail to see
>why people would not move to mozilla because of marquee.
>I see no diemarquee.org movement trying to get rid of it in IE.
>our market share increased a bit even during the period we added it
Rather, exactly rather. Millions of users make mass demonstration and scan:
"Give us marquee! Give us marquee!".

And they install Mozilla instead of MSIE not thanks to it security, standards
compliance and usability but exclusively being inspired marquee support...

"I don't believe" - said Stanislavsky in similar cases. I consider that marquee
support doesn't affect to user choice or even affects negatively. And
overwhelming majority of my friends and coworkers consider same.

The only benefit of marquee (according bug 156979 comment 63) is preserving of
page layout. Scrollbar solves this problem by more considerate way. Your
arguments against?


    
    

    
  
I am baffled as to why you care _so_ _much_ about <marquee> but make so little
fuss about MNGs, our non-standard DOM support, our screwed up non-standard
inline box model, <blink>, and the myrad or other potentially annoying features.

The fact is that while _you_ find <marquee> annoying, a number of our users
(primarily in the Chinese market) like it, and find that many of their sites are
significantly better because of it.

If you are so irritated my this feature then either disable it or avoud sites
that use it. The fact of the matter is that most of our users don't even know
<marquee> when they see it, and have even less against it. A pref just for that
feature would simply complicate our UI while providing little tangible benefit
to the majority of our users.

    
    

    
  
OK, our dispute can be solved only by one way. Let chinese users (unfortunately
I know no one from China, maybe you do?) test scrollbar XBL and then share their
impressions in this thread.

    
    

    
  
> I am baffled as to why you care _so_ _much_ about <marquee> but make so little
> fuss about MNGs, our non-standard DOM support, our screwed up non-standard
> inline box model, <blink>, and the myrad or other potentially annoying features.

Nobody uses MNGs yet, DHTML animations are uncommon because it would take a
significant amount of programming to annoy the user, the box model doesn't
particularly bother me as a web surfer (I might gripe about it if it comes up
when I'm developing), and BLINK has a hidden pref (bug 106462 to put it in the UI).

The only annoyances that appear with any regularity, because of their easy use,
are BLINK tags and MARQUEE tags. They are dangerously popular on auction sites
(and you really can't "avoud [sic] sites that use it" because there may only be
one auction for the item you want).

As for the argument that there are no sites protesting Marquees... A simple web
search found me this site:

<http://mozilla.weebeastie.net/marquee.shtml> - The fix no longer works thanks
to David's actions. His complaint (a valid one) is that he cannot read scrolling
text on his passive matrix LCD screen.

    
    

    
  
Editing userContent.css still works.

    
    

    
  
"DHTML animations are uncommon because it would take a significant amount of
programming to annoy the user"

yet there are move dhtml marquees that <marquee> on the web...

    
    

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

    
    

    
  
Again: editing userContent.css is too complicated for unexperienced users.

Usability problems with marquee aren't far-fetched (see comment 74 and comment 81).

Many users wannot see marquee animation. I have asked 41 user in our company, 32
are against marquee autoscrolling, 7 think indifferently and only 2 are pro -
they are sales managers ;)

If you refer to chinese users to like marquee, please, let me hear them here or
communicate with them directly.

I still consider that the most constructive and convenient way to solve this
issue is fixing bug 177660.

And, please, do not combine in one preference disabling marquee and animated
images. Marquee and blink might be combined, but it willn't be sufficient if bug
177660 will be fixed.

    
    

    
  
Internal prefs and UI prefs need not map 1:1.

    
    

    
  
I know :) but there is a lot of pref tweakers and toolbars at mozdev.org ;)
Give us a pref in prefs.js, and we make the rest.

    
    

    
  
You have a pref, it's in userContent.css. :-)

    
    

    
  
It isn't a pref, alas. Pref is string in prefs.js, afair ;)

Concerning blink - if bug 177660 will be fixed, we could remove C++ code for
browser.blink_allowed pref (is it what David Baron wants in comment 67?) and
make <blink>-binded XBL to read user pref and allow/suppress blinking.

    
    

    
  
No, a blink pref couldn't be implemented in XBL because we need to turn of
'text-decoration: blink' in addition to HTML's BLINK element.

    
    

    
  
Of course, but there are two similar, but different things relating blink.
text-decoration:blink is a valid CSS property, but <blink> is non-standard
extension from older Netscape browsers. Enabling CSS blinking and suppressing
<blink> tag might be an allowable choice, especially in strict HTML/XHTML mode.

    
    

    
  
Why does this have to be so much more complicated than it actually is?

* A pref in the UI to turn off scrolling marquees.
* A pref in the UI to turn off blinking text.

Why entangle all this political correctness, quirks vs. standards, and tedious
workarounds? In the time we've spent debating it in this bug, someone could've
written a patch to add those two options to the UI and this would be done.
Instead we have to do everything "my" way, with the "my" referring to each of
the people who has added comments to this bug. If anyone can just get the change
made, everyone can mark the checkbox the way they want it and be happy!

    
    

    
  
Skewer, I agree with you, but problem is slightly deeper.  We all have an
intention to solve this bug, we discuss how to do it. David justly consider that
superfluous forks in C++ code complicate developing and debugging.

If you really want to help us, please pay attention to bug 177660. If we'll fix
this and write XBL with fork depending of marquee pref, corresponding UI is
that'll come.

    
    

    
  
I disagree that allowing prefs to be read from XBL and complicating the XBL is
the right solution.  I think the right solution is coming up with a better
mechanism for generating a stylesheet from preferences.

    
    

    
  
Maybe, you're right... but my reason is this:

I still consider scrollbar to be the most adequate emulation for <marquee> tag.
But if we'll accept your proposal, we should write two XBLs separately for
autoscrolling and for scrollbar. These XBLs will be very similar, differences
will be present only in three CSS parameters and in autoscrolling module. See
"durty hack" at http://bugzilla.mozilla.org/attachment.cgi?id=97516&action=view

Fork in united XBL might economize our work and reduce overall number and size
of files.

More, in the future this opportunity (reading prefs from binded XBL) might be
useful for another cases. For example, I sometimes think about adding in Mozilla
ability to support WML (markup for cellular phones) through binding XSL
transformation to <wml> tag.

And, finally, giving to XBL binded by html.css permission to read user prefs is
probably simpler and eleganter than implementing interface for preferences
dialog to edit userContent.css. I don't know what is a security bug 177639 (bug
177660 was marked as it dupe), but I hope that work at 177639 will have fixing
177660 as a collateral result.


    
    

    
  
btw, we had a Accessibility fair on Campus and the tools they showed us did the
following:

 - converting a page of text to one line of scrolling text (in big letters)
 - making the blinking cursor even bigger

:)

    
  
Keywords: mozilla1.4, 
          
            nsbeta1, 
          
            nsCatFood

    
    

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

    
  
Blocks: 119597

    
    

    
  
This bug appears to have been abandoned. Meanwhile Mozilla is still violating
Section 508 and the User Agent Accessibility Guidelines by not providing a
mechanism to the end user to turn off marquee. Can anyone else take this bug?

    
    

    
  
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

    
    

    
  
Renominating for nsbeta1 because:

Mozilla (and Netscape) violates Section 508 and UAAG because of this bug.

Users with epilepsy and vision impairment will be unable to use the browser
because of this bug.

A critical user satisfaction issue is introduced when irritating animation
effects like blinking and scrolling text are enabled and mandatory.

A patch exists for this bug.

If marking nsbeta1- again please explain your reason for disputing these
problems caused by this bug.
Keywords: nsbeta1- → nsbeta1

    
    

    
  
skewer: there is no patch that i can see.

    
    

    
  
A pref for this will do no good until plugin manager is enhanced to easily
toggle on and off things like Flash. Preferably "click-to-launch" mode for
objects would be implemented as well.

Ted Mielczarek created a prototype of that at
http://ted.mielczarek.org/code/mozilla/ but it only hides them, the plugin still
loads (a big problem for Java, where startup can drain a disgusting amount of
system resources).

Also I see his page now links to bug 169330.

Plugin click-to-view could DEFINITELY be a "can't go back to IE" feature. It's a
beautiful solution to flash ads (annoying) and java ads (annoying, and major
perf). When did it become acceptable for advertisers to appropriate our plugins?

    
    

    
  
don't touch netscape keywords
Keywords: nsbeta1 → nsbeta1-

    
    

    
  
Flash isn't our problem. If a user doesn't want Flash animation to appear he can
uninstall the plugin.

    
    

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

    
  
No longer depends on: 177660

    
  
Depends on: 59701

    
  
Keywords: sec508

    
    

    
  
*** Bug 270838 has been marked as a duplicate of this bug. ***
Assignee: dbaron → nobody
QA Contact: ian → style-system

    
  
Blocks: 438848
Priority: P2 → P3
Target Milestone: mozilla1.2beta → ---

    
    

    
  
This is a safety issue. I'd been using add-ons such as QuickJava to protect myself from animated gifs, but they aren't working with Waterfox 56 and aren't compatible with Firefox 57+. There is an about:config setting but it only works on some gifs.
See Also:  → 1680828

    
  
Severity: normal → S3

    
    

    
  
The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates, 33 votes and 55 CCs.

:emilio, could you consider increasing the bug severity?


For more information, please visit auto_nag documentation.


Flags: needinfo?(emilio)

    
    

    
  
We supports prefers-reduced-motion now, and sites can use it to reduce animations. We prevent animating marquee by default now.


Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(emilio)
Resolution: --- → WORKSFORME

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: