But if they add APIs specifically tailored to the currently most popular extensions they'll lose a lot of innovation potential and developer goodwill.
If they don't, their userbase might shrink, something that could prove even more painful...
Quote from: krake on 2017-10-01, 09:26:25If they don't, their userbase might shrink, something that could prove even more painful...Eh? But their userbase will shrink. Like you said, something like ClassicThemeRestorer will not work.
For me, Firefox was fairly serviceable since v.0.7, still called Firebird at that time, but Opera was always better. These days I keep Seamonkey around for sentimental reasons and Palemoon for great choices made in the interface and sensible conservative policies.
(nicknamed "whoops Phoenix was trademarked so let's switched to also trademarked Firebird")
...but from version 3 or so I thought it was serviceable. By 3.2, 3.5 or 3.6 it was almost good. Then Firefox 4 struck.
The final nail to the coffin came when Ben Goodger (the lead developer of FF) went from Mozilla to design Google Chrome. Look at the first two pics here.
Also, it's sad/funny how these comics can be summarized as "we looked at Opera, copied much of it and somehow made it worse in the process."
I suppose he means that "normally" (for some value of normal) separate windows would be separate processes and therefore it'd be harder to drag tabs around between them. But they still had to work around that! Unless all the windows are the same process and all the tabs separate processes? Regardless, they still had to deal with it in some way. He's just indicating there's a problem and they came up with one possible solution to the problem, and somehow that ties into the UI? Wtf?
First, they think that the process-per-tab idea is totally awesome. The idea is that a hung-up tab can be killed without affecting the rest of the app.
Somewhat less cynically, it does have security advantages to sandbox off tabs more properly both from your system and each other.
I think you may have misconstrued my remark about sandboxing tabs from each other. I wasn't talking about crashes. Preventing those is merely a nice benefit (or in early Chrome, a necessity ). I was referring to something like one tab reading another's cookies or other personal information.
I was referring to something like one tab reading another's cookies or other personal information.
Yes, I must have misconstrued, because "sandboxing" always sounds to me like kids fooling around, but presumably it's something different.
It's nothing wrong with shared cookies among tabs.
If one wants to isolate cookies so they don't run in the same session, that's what separate windows should be for.Unfortunately, Gecko won't isolate cookies even among windows. AFAIK there are Firefox extensions for multiple cookie sessions.
The site evilsnooper.com shouldn't be able to just get all the info from what I'm doing at privatebanking.com. The specific technology involved isn't terribly relevant to the point.
I fail to see why windows and tabs should behave any differently though.
At work, I help maintain a smartcard middleware that is provided to Belgian citizens who want to use their electronic ID card to, e.g., log on to government websites.
What's the big deal? The only thing I was able to extract from the manifesto-speak was that you can add bookmarks to your home screen. How's that a new thing? It was there in Windows 95, wasn't it?
As a user I always thought Android was nothing special, but mostly usable. Having looked at it from the developer side a bit recently it's the most hostile system I've ever had the displeasure of interacting with.
I can see bus schedules [...] being something you'd store offline for easy retrieval.
Do you have a specific list of grievances spelled out somewhere? On your blog?
In a POSIXer's view, Android system is CRIPPLED: thus the porting of existing libraries onto it is TOUGH. Please have this in mind. The basic obstacles in porting: 1.Android does not have or offers less/no access in its trimmed bionic C lib : 1>No SYS V shm.h/sem.h 2>Not standard pwd.h and getpwuid_r(),etc. methods 3>No locale.h 4>Not standard IP/IPV6 headers/support such as arpa/*.h ones 5>Not standard pthread. 6>No iconv funcs. 7>No intl/gettext funcs 8>No i18n support and wchar_t.
Page created in 0.082 seconds with 41 queries.