The default bug view has changed. See this FAQ.

text size (zoom) should be remembered across browser sessions, per-site

RESOLVED FIXED in Future

Status

()

Core
Layout
P2
enhancement
RESOLVED FIXED
16 years ago
6 years ago

People

(Reporter: Andy MacNamara, Assigned: dbaron)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {access})

Trunk
Future
access
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
Wishlist:

Mozilla should remember modified font sizes on a per-web-page basis. For
example, when I'm browsing on http://www.arstechnica.com/ on Linux, the font
size is very small, no matter what I set the default font size. I'm sure that's
because they override it, but when I Ctrl + to set the fonts bigger, all the
other web pages have their fonts too big.

Steps to reproduce:

Visit www.arstechnica.com on a highish resolution, notice the small size of the
fonts. Then press Ctrl + to make the fonts bigger until it's comfortably
readable. Then visit http://slashdot.org/ and see that the fonts are now too big
and press Ctrl - to set them back.

Now imagine that it would reset the fonts to normal when going to slashdot.org,
and then set them big again when subsequently visiting www.arstechnica.com.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 1

16 years ago
I was just ready to enter the same request as a new bug. I agree, many pages set
not only typeface but also font size too small so it is amlost unreadable. I
would suggest something like context menu on right click (somewhere around
"bookmark this Page" could be "remember magnification/zoom". I mean something
like the image blocking.
Reassigning to Pierre. 
Assignee: attinasi → pierre
Target Milestone: --- → Future

Comment 3

16 years ago
The original problem (arstechnica.com is displayed too small) was reported on 
Linux so it is probably a dup of bug 102199, which can be fixed by changing the 
screen resolution in the Moz prefs.

About the RFE, I'm marking a dependency on bug 86663 even though it doesn't have 
much to do with it.  The only reason I'm doing it is that IMO this bug has a 
lesser importance and much of the code will be in place when bug 83663 gets 
fixed.
Status: NEW → ASSIGNED
Depends on: 83663
Priority: -- → P5
Summary: Per-Site Font Sizes → [rfe]Per-Site text zoom

Comment 4

15 years ago
*** Bug 119241 has been marked as a duplicate of this bug. ***

Comment 5

15 years ago
*** Bug 128578 has been marked as a duplicate of this bug. ***

Comment 6

15 years ago
*** Bug 128578 has been marked as a duplicate of this bug. ***

Comment 7

15 years ago
Patch for this issue should also address embedders. Namely, it should be
possible for an embedding client to set zoom on a per-site basis (e.g. via nsIPrefs)
(Assignee)

Comment 8

15 years ago
Assigning pierre's remaining Style System-related bugs to myself.
Assignee: pierre → dbaron
Status: ASSIGNED → NEW

Comment 9

15 years ago
*** Bug 159727 has been marked as a duplicate of this bug. ***

Comment 10

15 years ago
*** Bug 155448 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Summary: [rfe]Per-Site text zoom → Per-site (site-specific) text zoom

Comment 11

15 years ago
*** Bug 181026 has been marked as a duplicate of this bug. ***

Comment 12

15 years ago
I filed one of the duplicate bugs below.  Bugzilla needs a more powerful search
engine to eliminate all these duplicates!  Anyways . . .

This problem applies to MailNews as well because some messages are different
sizes and I'm constantly having to resize (especially when people are in a
different country like Japan).

Does this need a separate bug for MailNews?

BTW . . . I think a page-specific zoom based on some history (doesn't need
dating) is the best option.  Even within a given domain, different pages are
different sizes all the time (SourceForge for one).  Then the domain behaviour
will only apply to those pages within that haven't had a specific resizing.

However, that all said ... this would be a much better/powerful feature if not
only text size could be remembered on a per-page/site basis but also other
options ... for example images, proxies, java, javascript, user agent -- and so
rather than having big lists of sites for each option, we remember all options
per site/page.  If people didn't want their normal history to handle this
behaviour because they wanted to clear it (typical sad reason being too much
pRoN), then you could have a separate permanent history to remember all options.
 It wouldn't need dates or anything like that of course . . .

Should I start a new bug for this RFE as well?  It obviously subsumes this one
completely, but would be more work.  It would just be sad to see all these
options get remembered individually on a per-site/page basis rather than all
sites/pages remember all options.

Comment 13

15 years ago
Just throwing in my ideas here - I hope nobody minds.

"I think a page-specific zoom based on some history (doesn't need
dating) is the best option.  Even within a given domain, different pages are
different sizes all the time."

Page-specific is too much. I think it should work on a hierarchy basis. 

I.e. if you set size on www.sourceforge.com, you get it for everything on there.
If you only set it on www.sourceforge.com/project1/ then you get it in
/project1, /project1/fred.html, /project1/a/b/c/mary.html, but you don't get it
in /project2.

An easier partial fix to this bug, which would handle some of the criticism,
would reset zoom to 100% whenever you go to a link in a different domain
(without remembering anything). This would at least be an improvement on the
current system for people who use zoom as intended.

I have a bad feeling that some users may 'always' use zoom (given that all the -
far too many - other size controls are essentially incomprehensible) at the
beginning of each session. I.e. they start Mozilla, hit ctrl + +, then begin
browsing. If people do this (I don't know, I'm just guessing), they would be
disappointed to find that zoom settings are forgotten or stored per-site.

It could be a preference - rather than hiding it deeply in dialogs, this could
be placed on the Zoom menu itself, an option:

/ Reset zoom between sites

If the full 'zoom memorisation' system was implemented, the option could be:

/ Remember zoom for sites

Turned off, the browser would behave as at present.

Comment 14

14 years ago
<aol>Me Too!</aol>

Galeon has this feature.  It rocks!

Just switched back to Mozilla & keep on manually changing zoom settings to get
my prefered text size & really hate having to do that!
Sounds like a nice feature - however, I think it calls for a better user
interface to the font-sizing. I've my text-zoon level is changing on a per-site
basis (even though it is based on my own choices from previous visits), a strong
visual indication that your text-zoon is other than default is necessary.

Chris Neale's Trivial (http://cdn.mozdev.org/trivial/) ads nice font size
controls (increase, decrease, and reset) to the Phoenix toolbar. Buttons like
these with a visual indication of your current zoom level (even just
highlighting the "increase font size" button if larger than 100% would suffice.
(Assignee)

Comment 16

14 years ago
*** Bug 208679 has been marked as a duplicate of this bug. ***

Comment 17

14 years ago
*** Bug 209505 has been marked as a duplicate of this bug. ***
*** Bug 217706 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

14 years ago
Summary: Per-site (site-specific) text zoom → text zoom should be remembered across browser sessions, per-site
(Assignee)

Updated

14 years ago
Depends on: 218302
(Assignee)

Comment 19

14 years ago
*** Bug 65571 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 20

14 years ago
Bug 65571 contains significant discussion of why we should do this, rather than
something else.

Bug 218302 would give us some of the benefits of fixing this bug, is simpler to
do, and the work there would be useful in fixing this bug.
Priority: P5 → P3
Blocks: 66896

Comment 21

14 years ago
*** Bug 222922 has been marked as a duplicate of this bug. ***

Comment 22

14 years ago
*** Bug 227169 has been marked as a duplicate of this bug. ***
*** Bug 227821 has been marked as a duplicate of this bug. ***

Comment 24

14 years ago
FYI: Ther is actually an extension for Firebird for those with bad eysight, who
rely on this feature.

See http://texturizer.net/firebird/extensions/#textzoom

HTH
*** Bug 228957 has been marked as a duplicate of this bug. ***

Comment 26

13 years ago
*** Bug 229949 has been marked as a duplicate of this bug. ***

Comment 27

13 years ago
230935 when opening a "New Tab" / Window, option to please keep the current
"View" / "Text Zoom" size
above # is somewhat related to this request.

For people with declining vision, at least we can start with a higher zoom
factor and keep it over multiple websites
(Assignee)

Updated

13 years ago
Priority: P3 → P1
(Assignee)

Updated

13 years ago
Priority: P1 → P2
Re comment #13

I agree with the hierarchical method over page-by-page, and it can be
implemented by a tree, which is everyone's favorite data structure, right? ;-).
The problem is, when a user has 80 different text zooms on a particular site,
and then the site changes, that'll create a huge mess. Therefore, we'll need
some way to reset all levels below the current one. Such a concept would escape
the grasp of the average user, so we really would need to be able to have the
user reset all remembered text zooms. Doing anything more would require a "Text
Zoom Manager" which would be too much work for such a little RFE, and this would
never get finished with everything else that is needed. The tree could be
traversed and flushed to a text file periodically from memory, and you could
then go into the text file and clear a large section or delete the file
altogether. That implementation would be simple, you'd read in the file to a
tree structure. It'd look something like this:

http://www.excite.com                 120%
http://www.excite.com/bar             150%
http://www.excite.com/foo             75%

And it'd be traversed and made into a tree as follows:

www.excite.com 120%
|________________ bar  150%
|_________________ foo 75%

first order traversal would then reconstruct the text file when this tree was
flushed from memory. Nothing with 100% would be saved in the tree.

One thing scares me about it, though... This file could get VERY big for people
that use text zoom a lot! Overhead to read a 2MB file like this on a standard
system, I estimate, would be about 500ms on startup.

>An easier partial fix to this bug, which would handle some of the criticism,
>would reset zoom to 100% whenever you go to a link in a different domain
>(without remembering anything). This would at least be an improvement on the
>current system for people who use zoom as intended.

Ewww. People are going to moan about how they have to set text zoom on every
domain when clicking on links and how that's not good on their new 3200x2400
monitor. There is currently no pref afaik for default text zoom, so they'd have
to manually edit the font sizes, which most people won't have any clue about.
"And it'd be traversed and made into a tree as follows:" should be "And it'd be
_parsed_ and made into a tree as follows:"

I've thought about it and I agree now that setting it back to 100% is the best
option. Doing anything else would be more complicated, and if we:
1. Change http://www.domain.com/ to 75%, then everything in that domain would be
changed to 75%.

http://www.domain.com/                    75%

2. Then if you changed http://www.domain.com/foo/bar/baz.html to 50%, which then
set the foo level (highest level you haven't yet set) onward would be 50%.

http://www.domain.com/                    75%
http://www.domain.com/foo                 50%
http://www.domain.com/foo/bar             50%
http://www.domain.com/foo/bar/baz.html    50%

2. Then if you set http://mydomain.com/foo/ to be 80%, then the foo level would
be 80%, the bar level would remain 50% because its set.


http://www.domain.com/                    75%
http://www.domain.com/foo                 80%
http://www.domain.com/foo/bar             50%
http://www.domain.com/foo/bar/baz.html    50%

(In this case, if you went to http://www.domain.com/foo/weeee/, it would be
automatically set to 80% until you changed it, because that's what foo is)


2. Then if you set http://mydomain.com/foo/bar/plaza.html to be 120%, then:


http://www.domain.com/                    75%
http://www.domain.com/foo                 80%
http://www.domain.com/foo/bar             50%
http://www.domain.com/foo/bar/baz.html    50%
http://www.domain.com/foo/bar/plaza.html  120%

Therefore, when changing a page on one level, you have to go through each
previous level of an URL, and modify it until you get to a level that's already
said.

This creates a little dilemma, because if http://www.domain.com/foo/bar doesn't
have an index page, then there is no way to change it from 50%, meaning every
page opened within that directory will be 50% from then on, unless we allow the
most recent change to propogate upwards to the parent directory of a file... In
which case you'd have:


http://www.domain.com/                    75%
http://www.domain.com/foo                 80%
http://www.domain.com/foo/bar             120%
http://www.domain.com/foo/bar/baz.html    50%
http://www.domain.com/foo/bar/plaza.html  120%




Finally, we should only store things when changing the value. i.e. if you take
the example here as a representation of your tree:

http://www.domain.com/                    75%
http://www.domain.com/foo                 80%

Then going to http://www.domain.com/foo/bar/paz.html, even though it'd appear as
80%, would not modify the tree in any way, unless, say, you changed it to 100%.
Then it'd become:

http://www.domain.com/                    75%
http://www.domain.com/foo                 80%
http://www.domain.com/foo/bar/            100%
http://www.domain.com/foo/bar/paz.html    100%

And yes, contrary to what I said before, 100% would have to be possible within
the tree, if it is overriding a value set closer to server root.

Comment 30

13 years ago
*** Bug 260143 has been marked as a duplicate of this bug. ***

Comment 31

13 years ago
What I'm looking for is this: Firefox opens to my home page. The default text
size is too small. I increase the text size to the next level and shut down
Firefox. The next time I open Firefox and my home page comes up, I want to have
it open with the text size I prefer, and to which I adjusted last time, instead
of having it revert to the default every time I open the browser, so that I have
to change the text size every time. If this is what everyone means by the zoom,
and if zoom stickiness is a sticky issue, then why at least don't the values
that I enter into Tools/Options/Fonts and Colors become my new default? Why are
they ignored when I open the browser - especially if you don't want to change
the "stickiness" of the zoom function? 
Changing part of summary to "text size" and keeping the word zoom in there for
people that use it to find this bug.
Summary: text zoom should be remembered across browser sessions, per-site → text size (zoom) should be remembered across browser sessions, per-site
> why at least don't the values that I enter into Tools/Options/Fonts and Colors 
> become my new default? Why are they ignored when I open the browser

If they don't, that sounds like a bug. Please file a new bug on the Firefox 
product and cc me (ian@hixie.ch).

Comment 34

13 years ago
He already did: Bug 260143
*** Bug 268427 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Keywords: access

Comment 36

12 years ago
I really love this Text Size feature because the default fonts look too small
and changing them do not work for many sites. However, I have to repeat the zoom
operation (Ctrl++) every time for new tabbed window or when launching a new
instance of Firefox. Firefox should remember the Text Size setting.

Comment 37

12 years ago
*** Bug 281053 has been marked as a duplicate of this bug. ***
*** Bug 277633 has been marked as a duplicate of this bug. ***
*** Bug 311809 has been marked as a duplicate of this bug. ***
*** Bug 311809 has been marked as a duplicate of this bug. ***
*** Bug 327956 has been marked as a duplicate of this bug. ***

Comment 42

11 years ago
Running Linux I just now noticed this problem in 1.5.0.1.

Comment 43

11 years ago
*** Bug 348692 has been marked as a duplicate of this bug. ***

Comment 44

11 years ago
this problem is more annoying linux because I think X windows users on linux often run much higher resolutions than windows.

I second the comment that Galeon used to do this really, really well. It would just remember my per-site preferences and I'd never have to repeat them.

Comment 45

10 years ago
Lots of duplicates of this one! (Hint, hint.)

Interface suggestions:

There should be a menu option under "View" to store the current zoom settings for the active site.

The per-site zoom prefs could be managed using an interface similar to the ones used for cookie handling, image blocking, and popup blocking. That is, users may enter a site or domain name, then specify a zoom level expressed as a percentage.

Updated

10 years ago
Depends on: 378549
Duplicate of this bug: 384875

Comment 47

10 years ago
(In reply to comment #46)
> *** Bug 384875 has been marked as a duplicate of this bug. ***

Sorry to be nasty, this is no duplicate to any of the above as far as I read. I'm not talking about closing and re-starting firefox. I open another tab in the background and the font size in the current tab changes back to default. This is no desire for increased convenience but an unwanted change made by firefox.


With the checkin for bug 378549, this bug is now fixed.  You should see the requested behavior in the latest Minefield nightly builds and in the upcoming Gran Paradiso alpha 6 release.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Comment 49

10 years ago
Does this fix apply to only Firefox (since bug 378549 was filed against that product) or all Gecko/Toolkit-based apps (eg SuiteRunner)?
(In reply to comment #49)
> Does this fix apply to only Firefox (since bug 378549 was filed against that
> product) or all Gecko/Toolkit-based apps (eg SuiteRunner)?

Yes, this fix applies only to Firefox.  But the content prefs service (bug 378547), which Firefox uses to store the values of the text zoom setting for specific sites, is in toolkit, so it's available to toolkit-based apps.

Thus SuiteRunner could implement this feature as well by porting over the fix for bug 378549.

Comment 51

10 years ago
Filed Bug 386363

Updated

9 years ago
Depends on: 419612, 425286

Updated

8 years ago
No longer depends on: 419612

Comment 52

6 years ago
I just noted that when turning off the chronicle / pages visited in the past, Firefox (6.0.1) won't remember these settings even in the same tab/session/page, so when I click on a link on the same page these settings are lost. When turning on the chronicle, everything works again, so the wish is to have this working at least while I am browsing on the same page/session when chronicle is off.
You need to log in before you can comment on or make changes to this bug.