Canvas is a pretty core part of the platform now; --enable-canvas doesn't make sense any more. This also gets rid of --enable-webgl as well, as it has a pref and doesn't have any non-core-OS link-time dependencies (and causes some problems on platforms where it's not supported).

Comment on attachment 401523 [details] [diff] [review] remove --enable-canvas [Checkin: Comment 2] I mentioned this in bug 513924 comment 17, it's good to get rid of stuff that doesn't make sense anymore. --- a/dom/interfaces/canvas/Makefile.in +XPIDLSRCS = \ + nsIDOMCanvasRenderingContext2D.idl \ + nsICanvasRenderingContextWebGL.idl \ + $(NULL) Nix the tabs, just use two-space indent here. Looks fine otherwise.

http://hg.mozilla.org/mozilla-central/rev/0544b8fb6531 Crap, missed the tabs comment -- will fix that next time I touch this file.

I disagree. I think it should be possible to disable this. I think <canvas> is against the idea of the web (procedural DrawLine() instead of semantic markup <strong>test</strong>), and many people dislike Flash. I must be able to remove this from the build, if I don't like it. There may also be custom distributions or mini/special browsers which don't need it and don't want it. Also, I have serious security concerns about WebGL. I read there's a pref, but I'd rather not have this in the build at all. Please keep the build flags. REOPEN.

This bug is called "get rid of", and this is clearly fixed. I filed a new bug 517659 to re-add the flags.

Serge, I think it's rather silly to *require* an email client to have <canvas> support in HTML mails.

Actually, Serge, should be a new bug.

Comment on attachment 429321 [details] [diff] [review] (Bv1-CC) Port it to comm-central [Checkin: Comment 11] (In reply to comment #7) > Actually, Serge, should be a new bug. I agree on should be a new bug, but since we are here. I am with ted (and his comments in other bug). for m-c. and as for c-c I don't see ANY reason to keep unsupported options around.

> keep unsupported options around The point is that they must be supported. I don't want OpenGL in emails or even RSS feeds!

(or <canvas> or plugins or whatever)

Comment on attachment 429321 [details] [diff] [review] (Bv1-CC) Port it to comm-central [Checkin: Comment 11] http://hg.mozilla.org/comm-central/rev/adcc3e59475b

(In reply to comment #6) > Serge, I think it's rather silly to *require* an email client to have <canvas> > support in HTML mails. Maybe. Yet I'm just synchronizing with Core, which I can't override(!)... (In reply to comment #7) > Actually, Serge, should be a new bug. Indeed: in this case, I just missed to use bug 534522 which I had filed previously :-/

> Yet I'm just synchronizing with Core, which I can't override(!)... OK, then I'm reopening this. It can't be that I'm required to allow OpenGL and whatnot when reading RSS feeds, with no way to disable it. Guys, HTML is a *semantic* language. I must be able to use Gecko as HTML renderer, without also getting purely presentational (and flashy) things like OpenGL. OpenGL and canvas has absolutely no business in HTML emails, blogs and similar places where I just want to have text with bulleted lists and links. That "we define what the web platform is" is totally irrelevant for Thunderbird and many other applications which embed Gecko for rendering rich text.

On, and on the mail/ check-in: based on which capability was this reviewed? Called is not a mail reviewer. https://developer.mozilla.org/en/Mailnews_and_Mail_code_review_requirements

Gecko is an HTML5 renderer, which happens to include things like Canvas, Video, and Audio. If you don't want canvas in "HTML emails, blogs, and similar places", then you need to filter the content in those things, because then they're not "HTML". This bug is RESOLVED FIXED, and please stop spamming this bug further.