34 thoughts on “Cocoa Firefox nightly builds on Mozilla FTP server

  1. Hi,
    nice to see that some FF developer still working on improvements. Not like the guys from the visual update (the theme part) who does everything the can to destroy the Mac Firefox.

    Regards

  2. great work on the cocoa – just a bug to file – running on two monitors, the auto complete on the google search and the auto complete on the url bar appears on the primary screen when the firefox application is on the second screen – very disconcerting πŸ™‚

  3. No seriously, Jon Hicks has an excellent point.

    Why call it Cocoa Firefox, if it is actually Camino?

    Or is this an entirely different branch of Mozilla than Camino? Two Cocoa Branches?

    I could understand Cocoa Firefox might get a lot more Diggs, or a higher technorati rating, but casual observers are likely to be confused to bits.

    It doesn’t help Camino being adapted, if this is Camino, if you call it Cocoa Firefox.

    If this is not Camino, how does it differ?

  4. The “old” firefox is build using carbon.. This is a set of api’s that came from os < X .. this allowed firefox to run on OSX and on older machines..

    because firefox is letting go of the older machines they can now start using Cocoa.

    Which would make it respond faster and make it look more natural on OSX.

    Firefox will still be build with XUL ( and not like camino be totally cocoa ).. But the os-dependent layer of XUL will be build with cocoa

  5. Cocoa Firefox is still the same Firefox you love (or hate), with its UI created by using XUL; it’s just some of the lower-level guts that are different. The only difference most Firefox users will notice (besides the latent bugs in the Cocoa implementation of parts of the Mozilla toolkit) is that Cocoafox will use some of the “blue buttons” in web pages that Camino has had a monopoly on in the past.

    Firefox is not becoming Camino, nor is Camino going away.

    A lot of people seem to equate Cocoa with “user interface created with Interface Builder” or “builds in Xcode” or “has blue buttons” or “supports Services” or “the only native apps on Mac OS X” or any number of other falsehoods and misunderstandings. (Apple hasn’t been particularly good about clearing up misinformation for end-users–who seem to think that “Cocoa” is the end-all of importance–and there are even some app vendors who perpetuate the misunderstanding….)

    But that’s not the case; as Josh has already said, Cocoa is just one way of programming an app on Mac OS X. Carbon, Cocoa, Java, even AppleScript apps can have the “blue buttons” of the Aqua appearance, Carbon apps can (and do) use Services, and you can even create the interface for your AppleScript app in Interface Builder; none of those things are specific to (or special about) Cocoa.

  6. Raymond’s comment explains well some differences (and myths) between Cocoa, and non-Cocoa…
    …But could someome (Josh?) please explain the reasons and benefits behind this particular branch of Firefox?

    It sounds to me like I can either:

    1. Run an ugly browser with great plugins and lousy integration into my OS
    or
    2. Run a gorgeous browser that seems so natural in OS X but is completely limited to anything innovative
    (guess which is which?!?)

    mindslip

    P.S. Clicking “Preview” doesn’t keep the fields filled in, so I can’t click “Post” after without cutting and pasting everything.

  7. mindslip: Cocoa Firefox replaces some of the old code with newer code, namely using the Cocoa APIs, hence the name. It will still be the same ole Firefox with the same ole extensions and themes. It’s UI will not be like Camino’s. The only visible change will be native looking forms on web pages.

  8. “It does use Cocoa. Cocoa is an API, like Carbon or POSIX or GTK, its not the same thing as Aqua, which is a visual scheme.”

    Sure, I know all this, I just find the name ‘Cocoa Firefox’ misleading thats all. Its sounds to me like an application written in Cocoa (i.e Camino), rather than an app that uses Cocoa APIs.

    I did add the smiley so that the tone of my comment came across right! I hope it didn’t sound ungrateful, as I am anything but!

  9. I don’t think the name Cocoa Firefox is terribly misleading. Camino is NOT Firefox in any way shape or form. They share engines. Camino does its own thing when it comes to the interface and such and can implement its own features. They could write their own script/plugin system to compete with the likes of Firefox, but it wouldn’t be compatable without XUL.

    Cocoa Firefox implies exactly what it says, it’s build against Cocoa instead of Carbon. As I’m understanding it, that should improve speed and it should mesh better with OS X (widgets and such) as has been said. I don’t understand why people think XUL is particularly bad or even slow. This wouldn’t be any different than having a build of Firefox built against Qt instead of GTK+ on Linux. It shouldn’t slow Firefox down to use XUL any more than it ever has on Windows. XUL isn’t a problem whatsoever.

  10. Great work.

    Even I don’t like very much Aqua buttons on webpages, I’m also sure that any customization on the buttons will be handled correctly, so that isn’t really an issue.

    But still, this is just the surface. I think that a complete port to the Cocoa framework will be a must-do step and will improve this amazing tool once again.

    Thank you. πŸ™‚

  11. “great work on the cocoa – just a bug to file – running on two monitors, the auto complete on the google search and the auto complete on the url bar appears on the primary screen when the firefox application is on the second screen – very disconcerting :)”

    Just as a note, I have had this problem with the official firefox build for OSX on dual monitors for a while. A FF restart after connecting the second monitor to my powerbook usually fixes the display anomolies you described. Cheers!

  12. Hum, well, last I heard there’s now extremly few things that can’t be made with Carbon and actually require Cocoa. And Carbon is more difficult to code but has faster execution speed than Cocoa in most cases.

  13. Hello,

    I personally do not see any real advantage in the implementation of Aqua like form elements such as dropdown menus, radio buttons and checkboxes for example.

    The current carbon builds of Firefox make it quite easy for web designers and web developers to customize the look and feel of form elements. The boldy and 3D Aqua like buttons of OS X do not look very nice on some web pages. I prefer to use CSS styles in order to bring my form elements on my web pages into the shape I desire.

    Furthermore, I believe the ability to change the border color or background color of a dropdown menu can be very helpful to visualize a faulty form entry or selection for example.

    The forwarded website URL shows in an effective way the functional necessity of CSS styled form elements.

    http://www.his-aero-col-par.com/contact/index.php

    Carbon like form elements are great for building cross-platform websites which have the same look and feel on Mac and PC. Let designers and web developers choose the look and feel of form widgets!

    graphically & sincerely,

    Marc Klein
    Pixel:Industries

  14. We do not plan to leave widgets looking like they do now in Cocoa builds. There is a lot of work to be done there, especially with respect to how widgets interact with CSS styles from web page authors.

  15. Users, however, expect their form widgets to look like the widgets of their operating system, not some garish creation of an author who, in many cases, is designing for Windows (and even “neutral cross-platform” looks end up looking like Windows and sorely out-of-place on a Mac).

    Consistent widgetry is also an aid to security for the user—if a form button always looks like an OS button, the user is always going to know that pressing that object will submit a form; if a button has been styled beyond recognizability, the user loses the ability to clearly see that clicking will submit a form….

  16. This said Mr. Smokey Ardisson, in your world we should all drive the same looking car, wearing the same clothes, living in the same looking architectural house, using Apple computers and iPods, … etc. pp

    You can easily replace a submit button by a simple GIF or JPEG graphic. Therefore, I do not see your argument in concern of security on this point. Otherwise one could believe every web developer who uses CSS to customize the appearance of form widgets on his website is a potential criminal.

    ” Long live the difference ”

    graphically & sincerely,

    Marc Klein
    Pixel:Industries

  17. The WebKit developers went trough the same dilemma, and found the best compromise in a set of rules based on CSS usage.

    IIRC, if only font properties are changed, the system widgets are used. If the size, border, padding or color are affected, a more neutral shape (aka dumb windows gray) is used. Not sure about the exact properties they defined as triggers, and their site is offline.

    Worth a look..
    http://www.google.com/search?q=+site%3Awebkit.opendarwin.org+form+controls

  18. Hmm, I installed Minefield, now have deleted it after a few unsuccessful attempts at running the app. Back to Firefox now, but all my extensions are greyed out. Can anyone help?

  19. This is awfully nice but I’m wondering what’s goign on with Cairo/Quartz. Basically Firefox on the Mac is unusable for me as long as #121540 lasts (I don’t see pages displayed properly even though I have the right fonts available).

    Who is doing the Cairo/Quartz? Ar there any estimates on the timeframe when it lands in the trunk?

  20. penguin said:

    « I don’t understand why people think XUL is particularly bad or even slow. This wouldn’t be any different than having a build »

    1. Get a Mac
    2. Download Firefox. Use it
    3. Download Omniweb. Use it

    That will speak for itself. But you are right on one point, XUL is not that slow. At least, not slower than the Mac port of Opera.

  21. I’m assuming the primary target audience for “Cocoa Firefox” is the average Mac OS X end-user. Most such users are probably not Objective C, Python, or Ruby, etc developers and even more of them not developers of any flavor at all. So while it’s true that Cocoa is technically an API, the name is unfairly expecting the average mac user to grasp the geek-speak of the name and not to confuse it with the more widely known meaning that median users associate with the phrase “Cocoa application”. In other words a more sophisticated feel marked by high osx-integration and exceptional user friendliness. This is in no way merely about cute little aqua aesthetics.

    Wikipedia reflects this sentiment as well (of course for all anyone knows I could have put this in there myself; I swear I did not and I also know wikipedia isn’t the word in stone), nevertheless, whoever wrote this understands what Cocoa means to non-programmers.

    “For end-users, Cocoa applications are considered to be those written using the Cocoa programming environment. Such applications usually have a distinctive feel, since the Cocoa programming environment automates many aspects of an application to comply with Apple’s Human Interface Guidelines.”

    Throwing down the technicality card is weak at best. I can prove to you that Kleenex isn’t a paper tissue but instead a registered trademark of the Kimberly-Clark Corporation. That said, many people often ask for a paper tissues as Kleenex; and 10 times out of 10 the person closest to the tissue box will hand them a paper tissue without need for clarification.

    Regular Mac users don’t care what an API is, nor should they.

    This has the feel of a Linux crew who touts their OS as a positive alternative to Windows, but just as soon as a nix-noob comes around asking noob questions, they get ridiculed due to the expectations projected onto them by the nix-nerdz.

    The fact that Cocoa technically refers to just an API is inconsequential since in the minds of the market share of OS X users, Cocoa means “OS X Pimpin!”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s