Bug 378549 implemented this in Minefield/Firefox. That is a product specific implementation, though. It would be nice to have this in Camino as well. (assuming that mozStorage can be used) In Minefield, it relies on a content prefs service (implemented in bug 378547) available to Gecko (in toolkit). See also bug 108391 comment #50.
Is there any reason not to confirm this?
We'd have to do a lot of work? ;) I think it's a valid RFE, and certainly Firefox, OmniWeb, and iCab have some implementation of site-specific prefs (though I'm not sure OW or iC do this).
Following the virtual paper trail, it looks like we already build the contentprefs service (it's js component and an xpt), so we'd just have to package it. You'd then have to hook it up (port bug 378549 and any follow-ups) and figure out UI, and probably implement bug 419609 and bug 419612 (with sane UI to begin with, more like our existing permissions/exceptions UI, you could probably do away with bug 419609). From skimming the other bugs, it sounds like having remembering zoom changes defaulting to on for all sites (domains) creates a bad (unexpected) user experience, but there are definitely a couple of sites I visit regulary where I'd like to opt-in to Camino remembering my text zoom level. Peter mentioned in the channel tonight he'd like some sort of default (content) zoom level: [10:45pm] peeja: you know how you can zoom with cmd-= and cmd--? [10:45pm] peeja: is there a way to set a default zoom level? [11:02pm] peeja: I wanted to make it bigger [11:03pm] peeja: I tend to zoom all of my tabs [11:04pm] peeja: it would be nice to have a default zoom in the prefs [11:04pm] sauron: sor-of bug 391299 [11:04pm] peeja: yeah [11:04pm] cl: ah, right. [11:05pm] peeja: that sounds nifty [1:47pm] sauron: peeja: do you vary site to site, or do you really want every single site zoomed in? [11:47pm] peeja: I'm not sure [11:47pm] sauron: ok [11:48pm] peeja: my thought was every site [11:48pm] peeja: but I hadn't thought about doing it by site [11:48pm] peeja: I mean, doing it by site would satisfy my needs [11:50pm] ilya: I think site by site is more flexible, but having a custom base would be helpful also [11:51pm] ilya: think about how many sites you visit just once -- it would be confusing to muscle memory to have to remember to zoom in on those, but not on sites you visit frequently [11:51pm] ilya: also you would end up with a bunch of junk in whatever database remembers zoom levels for various sites [11:52pm] sauron: custom base is probably a ton easier to implement, but it sounds less useful to more users [11:52pm] ilya: yeah [11:52pm] ilya: what I'm trying to say is that they could be complimentary [11:52pm] ilya: er [11:52pm] ilya: complementary [11:52pm] sauron: i think auto-remember is bad UI [11:53pm] ilya: sauron: yeah, it throws me off w/Firefox every time [11:53pm] ilya: sauron: yeah, it throws me off w/Firefox every time [11:53pm] sauron: and that's probably what philippe hates about fx, after being the one to file the Cm bug It's not clear whether this bug (assuming we hooked up content zoom as well as text zoom) is the *best* fix for peeja's use case, but it does sound like it should work.
Thinking about it more, I actually think I like the per-site version better.
1. Yeah, when I filed this bug, it was all new and shiny... 2. The auto-remember UI is what irks me most in the Fx implementation, and it is an all or nothing setting – together with the fact that it immediately propagates to all open instances of a site in background tabs/windows. The second issue got an about:config pref in the Fx 3.5 timeframe, though (bug 419612). 3. I still think the concept is nice - but I'd much prefer an UI that is more selective, and where the user is actively in control, e.g setting/remembering a (text) zoom level for sites that I visit frequently. Just adding a menu-item in the View menu : 'Remember zoom level' (for this site) would go a long way. * Omniweb's implementation suffers a bit from the same problem as Fx, as that it automatically remembers the (text) zoom for a given site. * site-specific user stylesheets (Opera, Omniweb, Gecko with @-moz-document) are only a solution for advanced users. (having a 'Remember zoom level' option would slash a good chunk out of my usercontent.css :-)) As for a custom base setting, I'm not sure. Sometimes, when tired, I just bump up the preferred font-size to 18~20px (and/or a higher minimum font-size setting than usual). That helps for sites that don't use font-size set in px. (*) (*) more famous or popular designers are going back to doing just that: http://cameronmoll.com/archives/2009/06/coding_like_its_1999/
I like "Remember zoom level for this site" :) We could indicate whether a value was being remembered on the current site by a checkmark (like the Text Encoding menu). I don't think that completely eliminates the need for some sort of "Show Cookies…"/exceptions list UI, but it might be good enough. I think there are enough of us now that think some sort of "better-than-Firefox" behavior and UI for this are worth doing, so confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: remember the value of the text zoom setting on a site-specific basis - Camino-version → Remember the value of text zoom and content zoom settings on a site-specific basis - Camino-version
This is a P3 on the 2.1 list, but I don't think anyone's actually working on it. I *think* we could get away with just hooking up a "Remember zoom level for this site" menu item/checkmark in terms of UI if we started and got time pressed, but we'd have to see.
Priority: -- → P3
Target Milestone: --- → Camino2.1
(In reply to comment #3) > Following the virtual paper trail, it looks like we already build the > contentprefs service (it's js component and an xpt), so we'd just have to > package it. I looked at this a while back, and packaging it is not sufficient to make, say, a contentprefs.sqlite file from Firefox work; in addition to hooking up to our UI, we'd have to do some other sort of hooking up (though this is probably covered in the "port bug 378549" statement in the next pgh of comment 3).
(In reply to comment #8) > (In reply to comment #3) > > Following the virtual paper trail, it looks like we already build the > > contentprefs service (it's js component and an xpt), so we'd just have to > > package it. > > I looked at this a while back, and packaging it is not sufficient to make, say, > a contentprefs.sqlite file from Firefox work; in addition to hooking up to our > UI, we'd have to do some other sort of hooking up (though this is probably > covered in the "port bug 378549" statement in the next pgh of comment 3). Basically implement most of http://mxr.mozilla.org/mozilla1.9.2/source/browser/base/content/browser-textZoom.js?force=1
Punting; given that this needs a bunch of UI, it's too late to start on it for 2.1.
Target Milestone: Camino2.1 → ---
You need to log in before you can comment on or make changes to this bug.