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.
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: