Earlier quoted context omitted.
Recently switched to firefox and am quite happy to see it has lots of feature I didn't think it had. Chrome allows me to do use the built-in search engine of any website supporting it by pressing tab and then typing my search query. In firefox, it seems what I have to do is type my search query than use my mouse to click on the wikipedia icon (or amazon/etc). This also requires me to setup said search engine in firef…
Ctrl + k, type search query, press tab, select search engine or add the one on the current page if it has any.
The Firefox Dilemma
161–170 of 208 posts
Re: The Firefox Dilemma
#162Earlier quoted context omitted.
Recently switched to firefox and am quite happy to see it has lots of feature I didn't think it had. Chrome allows me to do use the built-in search engine of any website supporting it by pressing tab and then typing my search query. In firefox, it seems what I have to do is type my search query than use my mouse to click on the wikipedia icon (or amazon/etc). This also requires me to setup said search engine in firef…
The search box is separate in Firefox (next to the address bar). You can get to it by typing Ctrl+K (Cmd+K on Mac). Once you type your query, you can use the Down Arrow or Tab key to navigate to the site/engine you want to use and then hit Enter. You can also rearrange the order of those search engines to make the frequently used ones easier to reach. If you don't mind a network round trip, you can also setup DuckDuc…
Re: The Firefox Dilemma
#163Earlier quoted context omitted.
Konqueror was "suicided" by KDE themselves, right about the time Apple picked it up to make WebKit. The truth is that working on browser engines is hard and unfashionable work, nobody in opensource really wants to do it. Every desktop environment made its crappy half-baked reimplementation when it looked like deep desktop integration was inevitable and Netscape was a black-box (the IE 4/5 era), then dropped it when F…
> Konqueror was "suicided" by KDE themselves, right about the time Apple picked it up to make WebKit. How so? The browser kept working nicely the whole time. Eventually Webkit was offered as a rendering engine option when development overtook mainline KHTML, but that was long after Apple first adopted it.
Re: The Firefox Dilemma
#164Earlier quoted context omitted.
I agree, and Chrome did that in one simple way: marketing and monopoly power. They leveraged their position in search and webmail to push people to switch, and hammered the message in mainstream advertising (on buses and newspapers, even in Europe). If they had pushed FF instead of building their own browser, now FF would be in that position - regardless of technical merits (which were minor, and basically boiled dow…
> I agree, and Chrome did that in one simple way: marketing and monopoly power. When Chrome came out, it was much faster than Firefox. IIRC, it was also an evergreen browser from the start and you could install plugins without restarting. It was in many ways a superior product.
It doesn't matter that much anyway - Google didn't make the difference by converting FF users, but by being better than Mozilla at pushing IE users to switch. Which, again, was not a technical issue at all. I would bet that 90% of those users never even tried FF. A lot of them installed Chrome on Windows so they could synchronize settings from their main device, i.e. an Android phone.
Re: The Firefox Dilemma
#165>I think about Chrome’s usurping of Internet Explorer (IE), and I wonder (antitrust and all aside) would Chrome have usurped IE if it wasn’t for IE stagnating? I remember when I was younger and jumped ship to Chrome - personally, it wasn’t about using Chrome because it wasn’t IE, it was about Chrome beating IE in a foot race and offering me a clean user experience. Chrome ate Firefox's lunch, not IE's. Firefox was th…
I agree, and Chrome did that in one simple way: marketing and monopoly power. They leveraged their position in search and webmail to push people to switch, and hammered the message in mainstream advertising (on buses and newspapers, even in Europe). If they had pushed FF instead of building their own browser, now FF would be in that position - regardless of technical merits (which were minor, and basically boiled dow…
Re: The Firefox Dilemma
#166Earlier quoted context omitted.
> Konqueror was "suicided" by KDE themselves, right about the time Apple picked it up to make WebKit. How so? The browser kept working nicely the whole time. Eventually Webkit was offered as a rendering engine option when development overtook mainline KHTML, but that was long after Apple first adopted it.
It was basically deprecated as a file manager, in favour of Dolphin, and all-around de-emphasized. It started lagging in development efforts. I have not really followed after about 4.2 (iirc), but at that time it already looked fairly dead in the water, at least in the attitudes emanating from the project.
Well sure, but I saw that more as splitting out the file manager and browser into separate apps, which seems perfectly sensible.
> It started lagging in development efforts. I have not really followed after about 4.2 (iirc), but at that time it already looked fairly dead in the water, at least in the attitudes emanating from the project.
Shrug. It was always a shoestring project in terms of how many developers they had, but the browser kept working well, was my experience.
Re: The Firefox Dilemma
#167I'm not sure even technical users care what engine their browser is using. I think most web devs would prefer a smaller number of engines. I use Firefox mainly for privacy and containers. Is there a good reason Firefox couldn't provide features based on Chromium/Blink too (like Brave)?
Re: The Firefox Dilemma
#168Earlier quoted context omitted.
I agree, and Chrome did that in one simple way: marketing and monopoly power. They leveraged their position in search and webmail to push people to switch, and hammered the message in mainstream advertising (on buses and newspapers, even in Europe). If they had pushed FF instead of building their own browser, now FF would be in that position - regardless of technical merits (which were minor, and basically boiled dow…
That's dishonest. At least, mark it as your point of view. I was eager to switch to Chrome when it came out because Firefox was very slow. Firefox 3 was terrible in that regard and it never got any better.
When Chrome came out sometime in Fall '08, I used it, and it was faster than whatever FF version I had installed. So I kept using it.
Re: The Firefox Dilemma
#169Earlier quoted context omitted.
Yeah. In the early days of internet, web won, because of its relative expressiveness and lack of -rigidity- structure, compared to gopher for example. Now we see that the same unbounded expressiveness led to a monolithic system within a system, that is only feasibly maintainable by large organizations. One program should do one thing, (and do it well): that's what leads to healthy systems. For me, it's not the bloate…
But the web has also allowed for things which are way more than document delivery; imageboards, for instance, weren't around before the web, and the fact of carrying images made them unsuitable for previous technology.
Re: The Firefox Dilemma
#170Hands down there is one objective thing that Firefox does well and nobody else comes remotely close. DOM access. For some reason Firefox is thousands of times faster than other browsers when it comes to executing the standard DOM API methods. I know that is a bold statement but it is easily verified with numbers using a perf tool. Chrome is faster at executing JavaScript than Firefox, but even still Firefox leaves ev…
My understanding is that DOM manipulation and queries will always be far far slower than the logical equivalent in JavaScript. Does "thousands of times faster" challenge that? Ie. React's virtual DOM is a phenomenal idea because it greatly reduces actual DOM interaction. Is it not really saving us much in Firefox?
That really depends on what you're doing.
Reimplementing querySelector in JavaScript (even if you do it on top of JS-only node representations, not on actual nodes) is likely to be slower than the built-in version, for example.
If you're doing a "modify-read-modify-read" cycle, then things are different because the contract is different: the DOM promises that reads will see all modifications, while some of the other systems built around it don't.
> Is it not really saving us much in Firefox?
It really depends on the shape of your workload. There are various cases where React's virtual DOM is pure overhead and just makes things slower.
[Disclaimer: I work on a browser rendering engine, and have done a fair amount of performance work, so I may have my biases about what I see in profiles.]