Slashdot Mirror

Dave Hyatt, one of the lead developers of Safari, has solicited comments and suggestions on his blog about how to better improve coordination between Apple's Safari group and the KDE Konqueror. team. Corporate support from Apple will have to follow, of course. I am sure that they are the main reason this coordination has not occured by now.

Dave Hyatt, one of the lead developers of Safari, has solicited comments and suggestions on his blog about how to better improve coordination between Apple's Safari group and the KDE Konqueror. team. Corporate support from Apple will have to follow, of course. I am sure that they are the main reason this coordination has not occured by now.

In any case, the patches that triggered this whole issue were perfectly manageable in size.

memory usage:
Firefox - 38meg
avengine - 22meg (antivirus)
IExplore - 11 meg

I see a lot of comments about the memory footprint that Firefox occupies. I used to worry about that too, until I discovered that Firefox dynamically allocates memory usage depending on how much you have available. So try not to get hung up on how much RAM Firefox seems to be sucking up, because chances are it's only taking from what's available. I noticed this in practice when I added another 256MB of RAM to my system and Firefox's mem usage grew accordingly.

Check out this thread for more: Memory leak ? - MozillaZine Forums

Greasemonkey is good and on asa's blog, platypus was mentioned which is a great new extension to interactively modify pages and generating greasemonkey scripts from your changes. Now, browse happy, worry free, and worship our common WWW illiterate god! I hate Microsoft, and Apple is cool, especially since OS X builds on open source.

*starts masturbating to the karma rating boost*

there are quite a few issues with the current nightly (but most of them are not that serious). See this post for some details

An excerpt from the firefox forums I posted to : http://forums.mozillazine.org/viewtopic.php?t=2510 92&highlight=

# IE has a very usable FTP 2-way client, Firefox has an FTP browser only.
# IE has a better password-remembering system.
# Firefox's Ctrl-F doesn't seem to search input form fields.
# IE's "mouse select jumps to word boundaries" is not perfect but better than Firefox's character based model.
# Ctrl-N in IE brings up a clone of the current window, complete with history. Firefox opens up my startpage...redundant, because I can easily launch it from the start menu.
# Ctrl-T in Firefox opens up a new and utterly blank tab...even more useless than the Ctrl-N behavior!
# IE shows undisplayable characters with box placeholders, Firefox uses question marks.
# Tabbing in Firefox doesn't doesn't reset the cursor blink cycle, or something, so you don't get instant confirmation that you're typing in the correct box.
# IE has better drag and drop editing of the toolbars, including the "File Edit View" bar. (I like compressing that bar, 5 small buttons, and the address bar all on one line.)
# Ctrl-O in firefox is the normal file open dialog...not as useful as IE's URL-or-file-browse feature.
# I wish Firefox had an option to let each tab have its own close button...often I want to quickly close a bunch of tabs based on their title, but instead I have to switch to each one and close it seperately.

Some of those are just matters of opinion, none are that that major, but IE does have some usability pluses.

Yes, FF's memory cache does seem to grow without limit. If I leave FF running for a week then it can often hit the 200Mb mark :( A bit of googling lead me to: http://forums.mozillazine.org/viewtopic.php?t=1720 41 You can set browser.cache.memory.capacity to a lower limit and seriously curtail FF's rampant memory usage. It's really a whole lot better with a smaller memory cache setting.

You could just run FireFox in Safe Mode and uninstall the offending extension.

Whatever.

Before more people bitch and moan, Binary Patching is going to be available for Firefox 1.1

So issues like these will only be a few kb away as apposed to 4megs (still a lot less than most of IE's updates).

This is already being worked on and should be in 1.1. ^_^ Check out ben's blog about it.

A quote: "Darin has figured out how to get binary patching working, and is working on a system for incremental background update download."

That is accepted. Even by the Firefox devs.

...given that Hyatt announced Acid2 compliance about ten days ago.

http://kb.mozillazine.org/ActiveX "Mozilla does not support ActiveX controls natively. However, a plugin for ActiveX controls support is available"...

http://weblogs.mozillazine.org/roc/archives/2005/0 4/acid2.html

There's been lots of speculation about which browser will get Acid2 working first. I'd put my money on Safari. The problem is that we're late in the Gecko 1.8/Firefox 1.1 release cycle and there are a couple of bugs that would be quite a lot of work to fix, and introduce significant risk, and they're just not as important as other work that we have long planned for 1.8 and some other strategic work that I'll blog about soon. We will get to it in 1.9.

I'm sure some will seize on this as an opportunity to say "Gecko developers don't care about standards" ... they're simply wrong, as anyone can tell by looking at the huge number of standards compliance bugs we fix in every release. And keep in mind that if everyone's #1 priority was always standards compliance, Firefox would never have happened. -Roc

Part 2
Use about:config to modify browser.download.manager.showAlertOnComplete
http://mozillazine.org/misc/about:config/

http://weblogs.mozillazine.org/roc/archives/2005/0 4/acid2.html

There's been lots of speculation about which browser will get Acid2 working first. I'd put my money on Safari. The problem is that we're late in the Gecko 1.8/Firefox 1.1 release cycle and there are a couple of bugs that would be quite a lot of work to fix, and introduce significant risk, and they're just not as important as other work that we have long planned for 1.8 and some other strategic work that I'll blog about soon. We will get to it in 1.9.

I'm sure some will seize on this as an opportunity to say "Gecko developers don't care about standards" ... they're simply wrong, as anyone can tell by looking at the huge number of standards compliance bugs we fix in every release. And keep in mind that if everyone's #1 priority was always standards compliance, Firefox would never have happened. -Roc

Part 2
Use about:config to modify browser.download.manager.showAlertOnComplete
http://mozillazine.org/misc/about:config/

browser.sessionhistory.max_viewers = 5

browser.sessionhistory.max_viewers = 5

Well For Firefox this will solve your issue http://kb.mozillazine.org/Emacs_Keybindings_(Firef ox)

If you want to restore Emacs key bindings, read http://kb.mozillazine.org/Emacs_Keybindings_(Firef ox)

This isn't really so much a review as a description of features currently in the nightly. Firefox 1.1 isn't expected until June at the earliest. The roadmap (http://www.mozilla.org/projects/firefox/roadmap.h tml) gives a rough overview of the timeframes involved right now, though it is not always accurate as it isn't updated frequently.

Honestly, Firefox 1.1 isn't even in alpha-release yet. To take some highly unstable code and to "preview" it is a bit premature right now. I would call 1.1beta a better time to 'preview' things, as hopefully by then there will be a feature freeze and things will have stabilized a bit. I'm not kidding about the unstable bit either: up until a couple days ago themes and extensions wouldn't install in the nightly builds.

In fact, an article like this does a disservice because it's misleading the /. crew. Yes, an incredibly fast back/forward feature has been checked in to the latest nightly builds, but what they won't tell you is at present this feature is DISABLED. While that doesn't mean it won't be enabled in the future and might be enabled for 1.1, as it stands this feature is off by default and only accessible through a custom pref, so in its current state it changes nothing for the average end-user.

This forums post gives a better idea of the new features to be expected in 1.1 with one line sentences: http://forums.mozillazine.org/viewtopic.php?t=2577 66

And back/forward can cache the rendered layout instead of having to re-render everything: http://www.mozillazine.org/talkback.html?article=6 567

I personally don't use Firefox. But I do use K-Meleon (uses Mozilla) and, just 15 minutes ago, found all the mozilla preferences in a nice table.

Not sensational, probably offtopic, but nice to be able to tweak some of the settings even Firefox doesn't give you GUI access to. I couldn't resist pointing it out.

and obviously Apple people are doing it too. But they say who they are and what they do, so you have some clue as to how authentic/informed they are. In any case, any serious company has formal policy on speaking on behalf of the company.

this looks pretty easy to understand to me it's all laid out in nice small txt files and the link to each txt says exactly what the patch does. http://weblogs.mozillazine.org/hyatt/archives/2005 _04.html#008042

"Firefox binaries for Linux without GTK2 and XFT (ex. for RedHat 7.x)"
http://www.elmundo.es/imasd/servicios/binaries/fir efox/

I understand why that can't simply be slapped into the KDE codebase but, c'mon -- is there now some obligation for everyone modifying GPL code to keep their modifications cross-platform? Apple's job is to improve and ship Safari, not to fix Konqueror.

With all due respect to Rusin and any other KHTML devs complaining, I don't get what the problem is. They're getting diffs in manageable chunks (some of which look directly usable), they're getting bugs pointed out and solutions offered -- it looks pretty helpful to me.

If this isn't enough info, I don't know what is. I suppose code for regression tests, etc. would be nice. But complaining about this is more likely to piss off Apple/Hyatt than to help. Plus, he does have his email address posted on his blog if you have questions. Or just post a comment, and I'd bet he'd answer it.

The code for the Acid2 test fixes was all given to you in a nice list of small easily applied patches (which was posted on /. no less), and you still can't manage to integrate it without having full logs of Apple's interval versioning system? Come on.

I'm getting really sick of the anti-corporate bullshit that gets thrown around so copiously by a certain faction of the OSS community. And it's not just Apple being treated this way either.
No matter how much a big corporation gives to the community in terms of money, code, paid personnel, free advertising, etc..., there's always some crank complaining that they're not giving enough, and they'll eventually turn on us.
Well, given the way we treat them, I wouldn't blame them for turning on us.

Looking at Safari developer Dave Hyatt's blog it looks like he's provided some patches. I'm sure it will take some work to get those into KHTML, but that seems to be a pretty good start to me.

The CANVAS element does use OS X APIs, but behind an abstraction layer that is platform-agnostic. Mozilla has in fact implemented CANVAS on top of Cairo in Firefox. The code can be easily merged for CANVAS if a suitable back-end graphics library exists underneath.

Posted by hyatt at April 28, 2005 12:00 PM

So I gather that Apple has done quite a bit of work to help out but time is something of a luxury that the KHTML team doesn't have a lot of.

I'm not sure Zack Rusin's response is entirely well thought out. Hyatt links directly to the individual patch files for each of the bugs in KHTML. I've scanned through them, and there isn't much OS X specific at all, except in files that are explicitly platform specific.

Look at http://weblogs.mozillazine.org/hyatt/acid3.txt as an example.

In one of the other patches, an APPLE_CHANGES ifdef was actually replaced with entirely cross-platform code.

The KHTML team would understandably like every change in Safari to be packaged up into a nice little independant patch, but it realistically cannot work that way. I'm sure everyone who has tried to contribute to a project maintained by someone else has had to wait before their patch was (or was not) accepted, and Apple really can't wait on the KTML devs. They have a job that needs to get done by a particular deadline (a deadline that doesn't apply to the KHTML devs).

The patches posted by Hyatt look really well done to me, and not at all representative of what Rusin is accusing them.

Will the patches appear in Konqueror (KHTML)?

These *are* patches to KHTML.

Quoth TFA:

Fix parsing of the REL attribute on links.

Disallow TABLE inside P in strict mode.

And so on. It's all there.

Will the patches appear in Konqueror (KHTML)?

These *are* patches to KHTML.

Quoth TFA:

Fix parsing of the REL attribute on links.

Disallow TABLE inside P in strict mode.

And so on. It's all there.

Will the patches appear in Konqueror (KHTML)?

These *are* patches to KHTML.

Quoth TFA:

Fix parsing of the REL attribute on links.

Disallow TABLE inside P in strict mode.

And so on. It's all there.

Had you bothered to read the blog, you'd have seen that he already published the patches there:

http://weblogs.mozillazine.org/hyatt/archives/2005 _04.html#008042

Will the patches appear in Konqueror (KHTML)?

In theory KHTML can pickup and use the patches that Mr. Hyatt has provided on his blog, so yes they could appear. The ball is generally in KHTML folks court to do what is needed (not knowing what deltas may exist between the two code bases that may slow patch application).

(using part of another post I already made...)

If you click the patch links he provides you find the following files have been modified and provided to the public...

The following are packaged in Apple's framework called WebCore.

khtml/html/html_headimpl.cpp
khtml/html/dtd.cpp
khtml/rendering/render_box.cpp
khtml/rendering/ render_block.cpp
khtml/html/htmltokenizer.cpp
kh tml/rendering/render_table.cpp
khtml/khtml_part.c pp

The following is part of KWQ which is used to bridge from KHTML to Cocoa and this is part of WebCore (Apple specific item but still public).

kwq/KWQPainter.mm

Even if Apple doesn't commit their changes back to KHTML, no big deal. They already commited a huge load of changes a while ago; I think the KHTML developers should praise Apple for that.

Dave Hyatt's article "Safari Passes the Acid2 Test" he added all patches he wrote to make Safari pass the Acid2 test. There' a lot of Objective-C code in there; KHTML isn't written in Objective-C.

Also interesting is how Hyatt says "Safari", not "Webkit", not even "Webcore", and no "KHTML" either.

But, yes, I agree that Apple should commit their changes where possible.

Robert O'Callahan has a blog entry about Acid2 and Mozilla. Basically, gecko is currently very late in a cycle and the fixes for Acid2 are the kinds of things that really need to happen early in a cycle.

Vidalinux is a gentoo-like system but the installation process is that of Fedora's with the usage of RedHat's anaconda installer. It also uses Portage as it's package manager and I've heard many impressed with it, here is a review stating that Vidalinux is Gentoo done right. Here is the review of Vidalinux and you can compare it with a review of Gentoo

Vidalinux is a gentoo-like system but the installation process is that of Fedora's with the usage of RedHat's anaconda installer. It also uses Portage as it's package manager and I've heard many impressed with it, here is a review stating that Vidalinux is Gentoo done right. Here is the review of Vidalinux and you can compare it with a review of Gentoo

Vidalinux is a gentoo-like system but the installation process is that of Fedora's with the usage of RedHat's anaconda installer. It also uses Portage as it's package manager and I've heard many impressed with it, here is a review stating that Vidalinux is Gentoo done right. Here is the review of Vidalinux and you can compare it with a review of Gentoo

Surely their innovators can create even better engine? One that is alot faster, renders better etc. etc

Surely their innovators can create even better engine? One that is alot faster, renders better etc. etc

If you want to read a real, confirmed Apple dev's thoughs, why not check out Dave Hyatt's blog?

As many others have repeatedly stated, the Slashdot rendering bug has been repaired already. Until Firefox 1.1, based on Gecko 1.8 (which contains the fix) is released, you can use the Slashfix extension, or alternately force a page reflow by changing the font size.

As for Firefox stability in general, did you follow the installation instructions? There are some pitfalls associated with the installation process, especially if you are upgrading from a previous version. The MozillaZine Knowledge Base is a good place to start.

Safari developer David Hyatt actually found a bug in the test, and the WSP had to update Acid2. Warning: Experimental Standards.

Safari developer David Hyatt actually found a bug in the test, and the WSP had to update Acid2. Warning: Experimental Standards.

The short answer is that no browser currently passes the Acid2 test. I'm pretty sure the Firefox team is working on it. I know the Safari team is working on it as their progress is being talked about on David Hyatt's blog: http://weblogs.mozillazine.org/hyatt/

None of the browser completely pass it, but Safari and Firefox are making progress. Right now, Safari's support is best, with firefox in 2nd place and Opera a bit further back in 3rd; Internet Explorer is so broken you can't even recognize the smiley face. There's a post on Dean Edward's blog that has been tracking progress.