Earlier quoted context omitted.
> 120 tabs open at any given time Are you exaggerating ? If not, may I suggest an alternative way to browse the web ? I use multiple virtual desktops. Each desktop logically caters to one task. Each browser window is logically grouped under one activity. For example my desktop may look like this : Virtual Desktop 1 ( Communications ): * Outlook * Lync * Flowdock etc Virtual Desktop 2 ( Development ): * ConEmu/ Comman…
On a different system, I had pretty much that. I've moved to Chromium, which is also slow but at least doesn't hang as often or as badly. I would do this: 8 or 16 gigabytes of RAM (got an upgrade) 8 virtual desktops, about 5 occupied with browser windows 1 to 20 windows per desktop 1 to 20 tabs per window That is likely 100 to 300 tabs total. No, I really don't want to close them. I want more open, but performance is…
Firefox Test Pilot
141–150 of 152 posts
Re: Firefox Test Pilot
#142Earlier quoted context omitted.
On a different system, I had pretty much that. I've moved to Chromium, which is also slow but at least doesn't hang as often or as badly. I would do this: 8 or 16 gigabytes of RAM (got an upgrade) 8 virtual desktops, about 5 occupied with browser windows 1 to 20 windows per desktop 1 to 20 tabs per window That is likely 100 to 300 tabs total. No, I really don't want to close them. I want more open, but performance is…
Have you ever heard of bookmarks?
Even if I didn't lose my state, reloading a bookmark is slow.
With bookmarks, deletion is a pain.
How would I even know when to bookmark something? I might open 10 links from a news site or search engine, each in a different tab. Do you propose that I bookmark them immediately, even though they are probably tabs that I will soon close and never wish to see again? If I see the page and think I want to consider it for a few hours maybe (or longer; how should I know?) do I bookmark it? Perhaps I should wait the few hours or days...? Why should I even have to make this decision?
Re: Firefox Test Pilot
#143Earlier quoted context omitted.
Okay, I would like to remove Hello and Pocket from Firefox. Do you think Mozilla will merge my pull request that I am empowered to initiate?
As though I said anything about merging into upstream, or about Hello/Pocket, or about "open source" meaning "dictating development with random patches". :P But sure, if there were a ten year-old bug about removing them, then I would certainly expect them to welcome such a patch.
Despite vocal and repeated requests and complaints, Mozilla refuses to back down and remove things that users did not ask for and do not want; instead Mozilla does things like sneak Pocket support in in a point-release without any advance warning or any chance for the community to give feedback. And note that Pocket has had a fully functional Firefox extension ever since it was Read-It-Later--there was absolutely no technical reason to build in support for Pocket and deprecate the extension.
Mozilla has never been forthcoming about the real reason for doing this. In fact, the few Mozillians who have spoken about it seem to have had no idea why it happened, either.
Instead all we get is vague "people want to save things, this makes it easier for people to save things" statements. Well, people want to use Facebook, too: where is the built-in Facebook plugin? Where's the built-in Netflix extension? Amazon shopping support? etc. Clearly the decision to build in new Pocket code had nothing to do with a principled policy of making things easier for users.
The only reasonable conclusion is that Mozilla cut a deal and is getting money for it. And if that is the case, what is to stop them from doing the same for anything else? What if Microsoft cuts a deal to build in Bing support? etc.
Re: Firefox Test Pilot
#144Earlier quoted context omitted.
Frankly, your response is indicative of the problems at Mozilla. You need to realize that behind every sarcastic, disdainful comment about Mozilla or Firefox is years, often nearly decades, of Firefox usage, contribution, and promotion. When people come to trust and rely upon a tool for getting work done for many, many years, and then the organization responsible for that tool starts changing priorities in ways that…
My response was solely critiquing an exchange which ended up looking like: if (requestFeature(x)) { complain(); } else { complain(); } That flow doesn't get anyone to a better place, but there are tons of ways to refactor it into productive dialogue. Let's do more of that. I promise you that I legitimately do hear the frustrations felt by long-time power users of Firefox. I don't agree with all of them, but I do my b…
Ok, that sounds nice, but is this yet another extension API that does it Chrome-style, restricting extensions to a solitary button in a solitary toolbar, rather than giving them the freedom to truly extend the browser and its UI? Because if I wanted handicapped extension APIs, I'd just use Chrome.
And besides, isn't that what Jetpack was supposed to be? How long until the next extension API that will get it right This Time?
One of the foundational pillars of Firefox is its powerful extension API, however messy and difficult-to-refactor it may be. Take that away, and it's just another browser, no better than Chrome.
Re: Firefox Test Pilot
#145Earlier quoted context omitted.
btw, regarding UI and extensibility, a suggestion that many advanced users want to give is: look at Vivaldi ;)
Vivaldi has amazing features, yes. But it is no real browser and only an advanced web app bundled with Chromium. Also, smashing a wrapper on top of Chromium with features and call it a day is one of the most stupid things ever which a group of developers can do. But Vivaldi shows what guys do when they have respect of power users. They add features we want and we prefer and not only features what simple users or Chro…
Why people value simplicity and minimalism and design more higher today than having customization features and options?
Re: Firefox Test Pilot
#146Earlier quoted context omitted.
Great! So now in like 2 years, hopefully I can simply use type="time" instead of implementing a half baked JS time picker or time validator. It's frustrating seeing them spend so much time on Firefox OS, Hello, etc. and not on making Firefox a really good, standards compliant browser.
I hear your frustration; people inside the company found some of those changes frustrating, too. Test Pilot is a step in a new direction that's more participatory and inclusive of the community, and injects a lot of data into the decision-making process. As far as web standards go, Gecko's the only open-source browser controlled by a nonprofit. The alternative is a webkit monoculture, a world controlled by Apple and…
If you ever decide to stop being the Chrome users and general less advanced users darling i think about using Firefox again. But until that point, alternatives here i stay.
Re: Firefox Test Pilot
#147Earlier quoted context omitted.
My response was solely critiquing an exchange which ended up looking like: if (requestFeature(x)) { complain(); } else { complain(); } That flow doesn't get anyone to a better place, but there are tons of ways to refactor it into productive dialogue. Let's do more of that. I promise you that I legitimately do hear the frustrations felt by long-time power users of Firefox. I don't agree with all of them, but I do my b…
> To your concerns regarding stable APIs: that's exactly what WebExtensions are designed to address: decoupling add-on APIs from implementation details so that we can keep add-ons working, even as we refactor Firefox to be faster, more stable, and more efficient. Ok, that sounds nice, but is this yet another extension API that does it Chrome-style, restricting extensions to a solitary button in a solitary toolbar, ra…
WebExtensions are likely to be The One True API. Chrome, Opera, Edge, and Firefox all support them, and we're all working on standardizing them at the W3C: https://www.w3.org/community/browserext/
> If I wanted handicapped extension APIs, I'd just use Chrome.
Though we're trying to avoid reinventing wheels, we're not limiting ourselves to Chrome's APIs. For example, https://bugzil.la/1242871 extends Chrome's webRequest API to provide additional metadata needed by the NoScript and RequestPolicy add-ons. The initial development is focused on Chrome parity, since that covers most add-ons, but once we get there you'll see more of an emphasis on landing APIs that are needed by existing, more powerful Firefox add-ons.
If you're an add-on developer yourself and are concerned about APIs you need, please fill out this survey so we have a record of it: https://docs.google.com/a/mozilla.com/forms/d/1PtRXcs9UHVMjg...
Re: Firefox Test Pilot
#148Earlier quoted context omitted.
I hear your frustration; people inside the company found some of those changes frustrating, too. Test Pilot is a step in a new direction that's more participatory and inclusive of the community, and injects a lot of data into the decision-making process. As far as web standards go, Gecko's the only open-source browser controlled by a nonprofit. The alternative is a webkit monoculture, a world controlled by Apple and…
Congratulations, guys! Really glad to see this finally shipped. It will ALWAYS be Ideatown to me;)
I know, the name thing, what can you do? I worked on Persona before this, so I guess I'm not surprised by the Mozilla enthusiasm for reusing project names.
Have you tried the Activity Stream add-on? Captures so much of what we wanted to do with Chronicle. It's amazing what that team was able to crank out in four months.
The Search add-on turned out really well, though I wound up having to rewrite it in XUL after the MVP feature set got trimmed. It took some pretty strange requestAnimationFrame hacks to get highlight stealing working, I blogged about it: http://6a68.net/2016/highlight-stealing-hack/
Let's round up the Chronicle alums and grab drinks in SF sometime!
See you in the comments section ^_^
Re: Firefox Test Pilot
#149Earlier quoted context omitted.
As though I said anything about merging into upstream, or about Hello/Pocket, or about "open source" meaning "dictating development with random patches". :P But sure, if there were a ten year-old bug about removing them, then I would certainly expect them to welcome such a patch.
I guess we're not understanding each other. My point is that Mozilla's development of Firefox is no longer user-driven. Instead it's about what Mozilla thinks users should want, and they can take it or leave it, and if it helps Mozilla make money, users should want it. Despite vocal and repeated requests and complaints, Mozilla refuses to back down and remove things that users did not ask for and do not want; instead…
> where is the built-in Facebook plugin?
Years ago Facebook Messenger was actually built into Firefox. I remember using it myself, but have no idea what's become of that effort since then. See https://www.facebook.com/notes/facebook-engineering/under-th... > Where's the built-in Netflix extension?
Users demanding Netflix support is literally the reason why Mozilla was strongarmed into adding support for EME, despite trying to hold out against it for so long. > Amazon shopping support?
Click in the search box, type a query, and at the bottom of the suggestions dropdown you'll see that Amazon is one of the search engines supported out-of-the-box. I actually use this fairly regularly. > What if Microsoft cuts a deal to build in Bing support?
Just like Amazon, Bing is already supported out-of-the-box, as is Google, Yahoo, DuckDuckGo, eBay, Twitter, and Wikipedia. Mozilla has regional partnerships where they get paid to install such search engines, so you'll get Baidu as your default in China and Yandex as your default in Russia. These even vary per platform: in the US, Google is the default on Ubuntu, and Yahoo is the default on Windows. If Yahoo collapses within the next few years, I fully expect Microsoft to begin paying Mozilla to make Bing the default on Windows.These default search engines are how Mozilla makes 95% of its income (donations are basically a drop in the bucket, and because of tax laws they aren't allowed to use donation funds to finance Firefox development anyway). Mozilla sees this as a problem and has been actively looking for ways to diversify its revenue streams in the past years (go read any of their past financial statements to see them explicitly categorize their over-reliance on search engine revenue as a potential threat to the company), which has led to things like FirefoxOS (in the hope that telecoms would toss some cash Mozilla's way) and the "suggested sites" on the New Tab page. This why I find it extremely unlikely that someone "cut a deal", because Mozilla would want people to know that they're succeeding at the task of finding alternate revenue streams.
Re: Firefox Test Pilot
#150Earlier quoted context omitted.
> To your concerns regarding stable APIs: that's exactly what WebExtensions are designed to address: decoupling add-on APIs from implementation details so that we can keep add-ons working, even as we refactor Firefox to be faster, more stable, and more efficient. Ok, that sounds nice, but is this yet another extension API that does it Chrome-style, restricting extensions to a solitary button in a solitary toolbar, ra…
> How long until the next extension API that will get it right This Time? WebExtensions are likely to be The One True API. Chrome, Opera, Edge, and Firefox all support them, and we're all working on standardizing them at the W3C: https://www.w3.org/community/browserext/ > If I wanted handicapped extension APIs, I'd just use Chrome. Though we're trying to avoid reinventing wheels, we're not limiting ourselves to Chrom…
I'm actually not, and one reason is because I've seen over the years how extension authors have to keep up with the churn constantly breaking things, and that's not a pool I want to wade into. I'm amazed that, e.g. the Pentadactyl authors have the time and patience to do so.
So, if this new API stabilizes things long-term, that's fantastic. I would love to have extensions that never break again.
But forgive me for being skeptical, because with the CADT-style development models ruling the world nowadays, what usually happens is, the old API is deprecated and dumped before the new one has feature parity, leaving authors and users hanging. And with Mozilla's trend of imitating Chrome, this seems even more likely.
I can hear the cries now of, "The old API is too hard to maintain, so we're removing it in Firefox 72. We hope to reach approximate feature parity by Firefox 84, but we do not plan to reimplement all features in the new API. Regrettably, this will prevent some addons from being ported to the new API," with the implied, "But 'no one' [compared to the number of users on the Internet] was using those addons anyway, so who cares." And cue me switching browsers.
Please prove me wrong. :)