Camino 2.0RC1, please test [do not post to update sites]

[cflawson]

since the "back" function from backspace still didn't make it back, I guess we'll have to learn to live with this regression ?

That bug was fixed:

https://bugzilla.mozilla.org/show_bug.cgi?id=379812

but you should make sure your browser.backspace_action pref is set to 0 in order for it to work. If that pref is set to anything other than 0, it disables the delete-as-back action.

cl

[corranito]

no it does not work for me
my browser.backspace_action pref is well set to 0
i'm running on 10.4 on a powerbook g4
just tried it on a clean profile, doesn't work either

[Hard Nard]

I dropped back to 1.6.10, this build is maxing my CPU to the point that its unresponsive and I had to force quit to recover.

[j.a.duke]

Is there a location in which I can store, other than the Camino binary proper, the Firefox PDF plug-in pieces to get PDF rendering inside 2.0b+?

No.

Also, I was seeing some crashing with 2.0b4 and fx-quartz-pdf-1.1.2. I'll test with rc1, but wanted to see if there was a known problem.

Yes, it's a known problem that the plug-in crashes Camino; it's doing something bad.

You should not use the Firefox plug-in; the Schubert PDF Browser Plug-in (free for personal use) is much better behaved.

Is this a recent change? I was using the FireFox plug-in with good success until 2.0b4.

Is there a way to use the Schubert plug-in only in Camino? I'd rather use the native OS X pdf viewer in Safari & OmniWeb (since I support people using systems without the plug-in, I need to be able to replicate what they see & experience).

Thanks.

Cheers,
Jon

[Uncle Asad]

You should not use the Firefox plug-in; the Schubert PDF Browser Plug-in (free for personal use) is much better behaved.

Is this a recent change? I was using the FireFox plug-in with good success until 2.0b4.

No, it's been crashing people as long as it's been available. Some people it starts crashing right away, but others it seems like it takes longer.

Is there a way to use the Schubert plug-in only in Camino? I'd rather use the native OS X pdf viewer in Safari & OmniWeb (since I support people using systems without the plug-in, I need to be able to replicate what they see & experience).

It's a bit hacky (but less hacky than scattering the pieces of the Firefox plugin all over Camino), but you can stick the plugin in Camino.app/Contents/MacOS/plugins (and reinstall it after each upgrade). It's probably worth writing Schubert and seeing if he could add some sort of user default (preference) that his plug-in could read to not load in certain browsers (I'm not sure it's possible, but it can't hurt to ask).

[j.a.duke]

You should not use the Firefox plug-in; the Schubert PDF Browser Plug-in (free for personal use) is much better behaved.

Is this a recent change? I was using the FireFox plug-in with good success until 2.0b4.

No, it's been crashing people as long as it's been available. Some people it starts crashing right away, but others it seems like it takes longer.

Is there a way to use the Schubert plug-in only in Camino? I'd rather use the native OS X pdf viewer in Safari & OmniWeb (since I support people using systems without the plug-in, I need to be able to replicate what they see & experience).

It's a bit hacky (but less hacky than scattering the pieces of the Firefox plugin all over Camino), but you can stick the plugin in Camino.app/Contents/MacOS/plugins (and reinstall it after each upgrade). It's probably worth writing Schubert and seeing if he could add some sort of user default (preference) that his plug-in could read to not load in certain browsers (I'm not sure it's possible, but it can't hurt to ask).

Thanks for the tip about dropping it into the binary-I'll probably do that for now.

I had really good luck with the FireFox PDF plug-in until b4...

I did drop a note regarding the loading the Schubert plug-in into only specific browsers-I'll post what I hear.

Cheers,
Jon

[RPMozley]

Is it just my computer or does the bookmark bar appear lighter (on Tiger) than what's set in the source code?

I've played around with a few custom builds of my own and all appear to show lighter values than what is set. Oh, and I've been using the Digital Color Meter to provide the measurements.

[RPMozley]

Ok, I did a bit more testing and found out that the bookmark bar colours are being affected by my display profile. It appears to only change it at application start up, so if you change the display profile after opening Camino a new window will not update the colour and will only change after restarting Camino.
I did check that color management was still turned off, and it was.

Is this really expected behaviour?

[phiw13]

@RPMozley
Yes that is the case, more or less. I have two identical iMacs, to one point: one has a gamma set to 1.8, the other one set to 2.2 sRGB. The values as read by DigitalColor Meter are different, but perceptually, the toolbar looks identical. Colorsync in Action (tm).

And note,
1. the colour management software (lcms) that ships with Gecko has no effect on the chrome part of Camino. The latter is under control of the OS (that is unlike Firefox where everything is under control of the colour management software built into Gecko -lcms or qcms).
2. the display profile is loaded at start up in all cases. If you change your profile, you'll need to restart the app for changes to get through.

[RPMozley]

Well to me the bookmark bar definitely is different in colour, when using a profile with gamma that's not 1.8 and this shouldn't be the correct behaviour (I should know as colour management is my expertise). Strangely the rest of the toolbar does not change in the same fashion.
Maybe someone can point out to me what was done on the bookmark bar since 1.6.x (bugs @ bugzilla) and I'll have a look at the code changes.

[phiw13]

Well to me the bookmark bar definitely is different in colour, when using a profile with gamma that's not 1.8 and this shouldn't be the correct behaviour (I should know as colour management is my expertise). Strangely the rest of the toolbar does not change in the same fashion.
Maybe someone can point out to me what was done on the bookmark bar since 1.6.x (bugs @ bugzilla) and I'll have a look at the code changes.

I'm not aware of any changes to the bookmark bar toolbar on 10.4. There were some changes on 10.5, though (bug 401340) along with changes to the tab bar (applies to 10.4 and up)

[smokingpopsicle]

Is there a way to use the Schubert plug-in only in Camino? I'd rather use the native OS X pdf viewer in Safari & OmniWeb (since I support people using systems without the plug-in, I need to be able to replicate what they see & experience).

It's a bit hacky (but less hacky than scattering the pieces of the Firefox plugin all over Camino), but you can stick the plugin in Camino.app/Contents/MacOS/plugins (and reinstall it after each upgrade). It's probably worth writing Schubert and seeing if he could add some sort of user default (preference) that his plug-in could read to not load in certain browsers (I'm not sure it's possible, but it can't hurt to ask).

Where is the Schuber PDF Plugin installed by default? I'd need to know so I can move it to it's the new location you mentioned.

[cflawson]

Where is the Schuber PDF Plugin installed by default? I'd need to know so I can move it to it's the new location you mentioned.

I believe it's in (~)/Library/Internet Plug-Ins/ .

cl

[Uncle Asad]

I'm not aware of any changes to the bookmark bar toolbar on 10.4.

We did fix a bug to make it display properly on 10.4 in the background, or something like that (there was a small thread here about the problem some months ago), to match what it did in 1.6 (when we removed 10.4 ifdefs after dropping 10.3 support, some logic was changed accidentally by the absence of the ifdef, but all we did was restore the logic to the way it was in 1.6). But otherwise phiw13's right; there have been no changes to the bar on 10.4 that I'm aware of, either.

[RPMozley]

Thanks for pointing out those bugs for me, it did eventually help me track down the problem from what was done in bug 425519. Instead of using a device-dependent profile a generic RGB profile is used.
In further testing I got this behaviour to occur in Camino 1.6.10 by setting the minimum OS to be 10.4. Also I found a simple fix for it.

The next thing for me to do is file a bug on this and get a patch file ready to add.

EDIT: Bug 527248 filed and patch added.