Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multiprocess Firefox

billmccloskey.wordpress.com

Post reply on HN
Print view View original

101–110 of 126 posts

Re: Multiprocess Firefox

#101

Post by jaredsohn »

Crito wrote: post #93
diydsp wrote: post #56

Earlier quoted context omitted.

Hahaha, you and me and about 1% of the browser users (well on HN, probably more like 10%) have particular habits of keeping much larger numbers of tabs open than everyone else. Have you imagined an alternate scheme to tabs, where there are 100s of thousands of potential "tabs" which can be organized, called up in groups, moved in clumps together, and shared? Imagine each group of tabs like soldiers in a Command and C…

I think there is an opportunity to blend the concepts of tabs and bookmarks. Tabs could/should be aggressively swapped out to disk, or even unloaded entirely if the state that they have is unnecessary. Obviously we can just bookmark then close a tab today if we don't care about it's state, but that is not a workflow that the standard tab/bookmark UI facilitates. (The standard tab UI also does not facilitate massive n…

A slightly different workflow is to use the OneTab Chrome extension (https://chrome.google.com/webstore/detail/onetab/chphlpgkkbo...) which with a single clicks converts all of your tabs into a list that can later be reloaded.

Re: Multiprocess Firefox

#103

Post by asadotzler »

wmf wrote: post #100
rbanffy wrote: post #88

Earlier quoted context omitted.

> Interesting that they chose to share code with Chrome. Since the two are competitors, I would have thought that they'd use completely separate implementations. That's what open source is about: collaboration instead competition. Why compete when you can pool your resources together.

Mozilla does have a habit of rejecting code like WebDB/SQLite and PNaCl, so people are always surprised to see them reusing code, especially from Google.

Those weren't rejections of code as much as they were rejections of specifications and features.

Re: Multiprocess Firefox

#104

Post by cpeterso »

fenesiistvan wrote: post #15

My biggest problem with Firefox is its startup time. It takes much longer to start the firefox.exe then IE and Chrome which are both very fast. I am using Win7 on i7-3960X, intel SSD, 16 GB RAM. If I install any plugin then this thing is much worst. (For this reason I am not using any plugin which is a big loss). It is weird that this issue is seldomly mentioned, but I think that it is much more important then the ot…

Tom's Hardware Guide's "Web Browser Grand Prix" measured Firefox's startup times being much faster than Chrome, for both cold and warm starts and single and multiple tabs.

http://www.tomshardware.com/reviews/chrome-27-firefox-21-ope...

Re: Multiprocess Firefox

#106

Post by mburns »

diydsp wrote: post #56
RHSeeger wrote: post #35

Earlier quoted context omitted.

I'll admit I wasn't a fan of process-per-tab originally either. However, since ever browser leaks memory, the ability to close some windows and reclaim the memory that was lost has been very useful to me (I tend to have 50+ tabs open at most times, and for many days at a time). That being said, I'd also be ok with process-per-window, as that would give me the same basic ability.

Hahaha, you and me and about 1% of the browser users (well on HN, probably more like 10%) have particular habits of keeping much larger numbers of tabs open than everyone else. Have you imagined an alternate scheme to tabs, where there are 100s of thousands of potential "tabs" which can be organized, called up in groups, moved in clumps together, and shared? Imagine each group of tabs like soldiers in a Command and C…

That's precisely what Tab Groups are meant to do. And Firefox can be set to not keep background tabs in memory.

So yea, that behavior is quite possible today.

Re: Multiprocess Firefox

#107

Post by JohnBooty »

wmf wrote: post #100
rbanffy wrote: post #88

Earlier quoted context omitted.

> Interesting that they chose to share code with Chrome. Since the two are competitors, I would have thought that they'd use completely separate implementations. That's what open source is about: collaboration instead competition. Why compete when you can pool your resources together.

Mozilla does have a habit of rejecting code like WebDB/SQLite and PNaCl, so people are always surprised to see them reusing code, especially from Google.

I didn't know they had a history of rejecting SQLite - what are you referring to?

They have used SQLite to store bookmarks since Firefox 3: http://kb.mozillazine.org/Places.sqlite

But that doesn't mean they haven't rejected it elsewhere. Was just curious.

Edit: I see now. The WebSQL de-facto standard, which Mozilla rejected, essentially said: "use SQLite." Here's a discussion: https://plus.google.com/+KevinDangoor/posts/PHqKjkcNbLU

Re: Multiprocess Firefox

#108

Post by Crito »

jaredsohn wrote: post #101
Crito wrote: post #93

Earlier quoted context omitted.

I think there is an opportunity to blend the concepts of tabs and bookmarks. Tabs could/should be aggressively swapped out to disk, or even unloaded entirely if the state that they have is unnecessary. Obviously we can just bookmark then close a tab today if we don't care about it's state, but that is not a workflow that the standard tab/bookmark UI facilitates. (The standard tab UI also does not facilitate massive n…

A slightly different workflow is to use the OneTab Chrome extension ( https://chrome.google.com/webstore/detail/onetab/chphlpgkkbo... ) which with a single clicks converts all of your tabs into a list that can later be reloaded.

Very interesting, thanks for the suggestion. I currently use Firefox and Chrome concurrently for various reasons, so I think I will probably get some use out of this.

Re: Multiprocess Firefox

#109

Post by nephyrin »

Too wrote: post #80

Can this also solve the issue of flash objects taking over all keyboard input and breaking the standard hotkeys?

Gecko plugin peer here: Unfortunately, no. NPAPI has two modes: windowed and windowless. In windowless mode (roughly): we proxy input to flash, and flash renders into a buffer we provide it. In windowed mode, we create a native OS child window for flash and let it handle input and rendering directly. In this mode, without a way for flash to pass "unused" keys back to us, it will require some ugly hacks to steal hotkeys from it reliably.

Most sites run flash in windowed mode, and for good reason - flash's performance sucks in windowless mode, and it cannot make use of hardware acceleration (IIRC). Since Adobe's NPAPI flash seems to be essentially in stability mode, it's unlikely this will be improved :(

Now, in current multiprocess mode, we actually force flash to use windowless mode -- because support for windowed mode isn't finished yet (bug 923746). But the aforementioned performance issues mean that we'll probably remove that restriction once we support windowed mode in multiprocess.

Re: Multiprocess Firefox

#110

Post by unknownian »

cpeterso wrote: post #104
fenesiistvan wrote: post #15

My biggest problem with Firefox is its startup time. It takes much longer to start the firefox.exe then IE and Chrome which are both very fast. I am using Win7 on i7-3960X, intel SSD, 16 GB RAM. If I install any plugin then this thing is much worst. (For this reason I am not using any plugin which is a big loss). It is weird that this issue is seldomly mentioned, but I think that it is much more important then the ot…

Tom's Hardware Guide's "Web Browser Grand Prix" measured Firefox's startup times being much faster than Chrome, for both cold and warm starts and single and multiple tabs. http://www.tomshardware.com/reviews/chrome-27-firefox-21-ope...

As a Firefox user, I must say that these tests don't mean much considering web browsers are updated every day to week to month depending on the version used. Each browser wins at one point.
Post reply on HN