←back to thread

288 points fernandotakai | 1 comments | | HN request time: 0.208s | source
Show context
nathanb ◴[] No.10039122[source]
It's the "no override" part that concerns me.

I created and maintain an extension that is used by visually-impaired people around the world (it has been translated by volunteers into Dutch and Chinese, for example).

Occasionally a Firefox update breaks this extension. OK, fine, that's the cost of doing business. Of course, the automated compatibility report that Firefox creates is utterly useless; it almost never catches the breakage. But that's a side rant....

There can be a decent turnaround lag (sometimes on the order of a few days) to get a new version of an extension reviewed by addons.mozilla.org. In the meantime, I have made a habit of building a new version of the extension and giving it to anyone who asks. Some people rely on it to use the web and can't wait for Mozilla to do their thing (another side rant: I once stupidly forgot to check in a key resource. I've since changed my development process to keep this from happening again. But the non-functional extension that I pushed passed Mozilla's review just fine. Makes me wonder how much value the review process is really adding.)

If I want to be able to continue this process, I will need to sign the extension myself (and who knows what histrionics Firefox will throw if a user tries to replace an extension with one that has the same UUID but a different signature!)

replies(8): >>10039130 #>>10039580 #>>10039659 #>>10039887 #>>10039941 #>>10040621 #>>10040999 #>>10041707 #
jsingleton ◴[] No.10039941[source]
I don't use many extensions but I'm finding I have to use more as Mozilla remove features from Firefox.

For example you can no longer set the User Agent string on a per site basis natively in Firefox preferences [0]. This would be very handy to force HTML5 video on BBC News when you don't want to install flash [1]. I only discovered this setting was deprecated by finding that bug report whilst researching the blog post.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=933959

[1] https://unop.uk/dev/how-to-watch-bbc-news-videos-on-a-deskto...

replies(2): >>10040237 #>>10040605 #
chriswarbo ◴[] No.10040237[source]
> I don't use many extensions but I'm finding I have to use more as Mozilla remove features from Firefox.

To me, that's the way Firefox should work: a fast, lightweight browser, with a powerful extension system.

I get disappointed when Mozilla add "features" to Firefox, like PDF viewers, Pocket, etc.

replies(1): >>10040445 #
TazeTSchnitzel ◴[] No.10040445[source]
The PDF viewer is rather important if only for security.
replies(2): >>10040709 #>>10042981 #
chriswarbo ◴[] No.10042981[source]
I disagree. Having no PDF viewer is more secure than having a PDF viewer.

I'd have no problem with Mozilla releasing a separate PDF viewer, either as an extension, a standalone application or even a Web site. I also have no problem with Mozilla setting Firefox's default PDF application as a stub which downloads their separate viewer. But it shouldn't be built in to Firefox.

In any case, it is not the job of a Web browser to subvert the user's OS setup.

replies(1): >>10044955 #
TazeTSchnitzel ◴[] No.10044955[source]
> I disagree. Having no PDF viewer is more secure than having a PDF viewer.

No, because that means you still do have a PDF viewer, but it's whichever the user has installed, most likely Acrobat, which is vulnerability-ridden.

> But it shouldn't be built in to Firefox.

Why shouldn't it? Browsers aren't limited to HTML. They also support plaintext, SVG, many image formats, XML, and so on. What's wrong with supporting PDF?

replies(1): >>10047313 #
1. chriswarbo ◴[] No.10047313[source]
> No, because that means you still do have a PDF viewer

I didn't say "having no PDF viewer in Firefox", I said "having no PDF viewer".

> Browsers aren't limited to HTML. They also support plaintext, SVG, many image formats, XML, and so on. What's wrong with supporting PDF?

I would call that feature creep; even so, there are still a few differences:

HTML provides mechanisms for embedding images[0], so trying to support some common formats in the browser is a reasonable approach. A better approach would have the OS handle image formats, eg. like the datatype mechanism in AmigaOS[1].

The example image formats at [0] include single-page, non-interactive PDFs. Supporting such an image format might be reasonable, although I've never seen such a thing used in the wild. That's not what Firefox provides, though. Instead, it provides a whole application embedded in a tab, with a GUI for navigating around documents. The equivalent analogy for images would not the facility to decode the format; it would be the bundling of a whole image browsing GUI like Gwenview[2], which I certainly would object to. As it stands, FF treats a standalone image file as if it were a standalone img element, which is perfectly reasonable. The same goes for plain text, which FF effectively treats as if it were in a pre element. Again, it doesn't provide a special application for navigating text files.

SVG is also specifically mentioned in the HTML spec[3], hence providing browser support for SVG isn't straying too far from providing support for HTML. Again, FF doesn't provide a embedded GUI application for navigating SVGs (unless you count the Web Inspector stuff, which also has no place in the browser and should be either a separate extension or rolled into Firebug).

XML is just a syntax, which browsers need to support if they want to support XHTML[4], in the same way they need to support UTF-8 as a syntax for representing the text in HTML documents. Hence it's completely in-scope.

[0] http://www.w3.org/TR/html5/embedded-content-0.html#the-img-e... [1] http://wiki.amigaos.net/wiki/Datatypes_Library [2] https://userbase.kde.org/Gwenview [3] http://www.w3.org/TR/2010/WD-html5-20100624/the-map-element.... [4] http://www.w3.org/TR/html5/introduction.html#html-vs-xhtml