61–70 of 71 posts
Earlier quoted context omitted.
And that's precisely why you shouldn't be using them. We developers are some of the worst people at understanding what's actually important and what's not to a user's workflow.
> And that's precisely why you shouldn't be using them. With a userbase of precisely one, I can do whatever I want. :-)
I also hope FireFox would prevent HTML5 YouTube videos form autoplaying and autoloading. They will implement a such feature in the next version, but it doesn't seem to work properly now (It's beta, I know). And it's not clear to stop autoloading, either. Does anyone have a good idea to block autoplay and load HTML5 videos? http://www.ghacks.net/2015/06/11/finally-mozilla-adds-workin...
This is amusing. There are bugs opened for 10 years that are infuriating though, like https://bugzilla.mozilla.org/show_bug.cgi?id=307089
Given that in the setting of that bug report the user has explicitly instructed the browser to not store anything anywhere, and that you don't like the third option (the current behavior), I assume your proposed solution is to put up some sort of error message instead of showing the source in this situation?
Hmm. How many animated favicons have you noticed? I can't think of any...
I've seen zero animated favicons. I'm wondering if it's a "feature" that doesn't work on Linux. The URL bar doesn't even display favicons anymore, although they show up without animation in bookmarks.
Earlier quoted context omitted.
I think it would be possible to configure noscript to allow scripts, but require a click to play media (I haven't actually tried it like that, since I just keep almost all scripts blocked anyway).
NoScript has a configuration option allowing you to set HTML5 content as click to play.
If a browser blocks animated favicons, I can see that blocking sites that dynamically update the favicon with a badge to show unread messages / new updates / etc.
Am I missing something or are a lot of people confusing animated favicons (animated gif as favicon, as per the linked article) with dynamically setting the favicon?
Or rather: you can simulate animated gifs with dynamically setting the favicon. And as such blocking animated gifs wouldn't do anything beyond driving people to use JS to animate them instead.
So, realistically, either block both, block dynamically setting it but allow animated gifs, or keep both. But blocking animated gifs but allowing people to dynamically set it won't do much of anything.
Personally, I'm for blocking animated gifs (or rather, making it a config option), and throttling dynamically setting the favicon (like how FF already throttles background JS events). Unfortunately, given FF's push towards no options, I very much doubt it's going to happen.
This is amusing. There are bugs opened for 10 years that are infuriating though, like https://bugzilla.mozilla.org/show_bug.cgi?id=307089
There is no magic. Either the browser stores the source somewhere or the browser refuses to show source or the browser refetches the source from the server when asked to show it. Given that in the setting of that bug report the user has explicitly instructed the browser to not store anything anywhere, and that you don't like the third option (the current behavior), I assume your proposed solution is to put up some so…
I have an idea, if you don't like something a site does, stop using it.
I really don't get that logic. To me what you're saying is equivalent to saying that we should never discuss anything. Something's wrong with the society? If you don't like it, you can just move to a different country. How can we possibly improve anything with that mindset? I know that I'm overreacting here, but I would genuenly like to here comments about that.
Edit: And most importantly, I think the site developers/designers/whatever should be free to do anything they want that is technically possible, that isn't a security threat. Funny thing is that I saw an animated favicon this morning,and remembered this thread.
Earlier quoted context omitted.
There is no magic. Either the browser stores the source somewhere or the browser refuses to show source or the browser refetches the source from the server when asked to show it. Given that in the setting of that bug report the user has explicitly instructed the browser to not store anything anywhere, and that you don't like the third option (the current behavior), I assume your proposed solution is to put up some so…
I suggest to do it like Chrome does, show me the source. Maybe it caches the original source, I don't know, but I can't imagine that's expensive (given all that Firefox caches on each tabs ...).
The key part here is that this bug report is about a situation in which the user explicitly changes the browser's default settings to not store stuff. And then the browser ... doesn't store stuff. Shocking, I know.