49770 - Bigger and Smaller don't work most of the time

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Akkana Peck]

Split off from bug 47463:

On Linux, at least, Bigger and Smaller don't work most of the time, whether via
keys or the toolbar buttons.  The first time I click Smaller, the selected text
gets smaller, but subsequent clicks have no effect.  The first and third clicks
on Bigger have an effect, but the second and anything past the third are no-ops.

Comment 1

[Akkana Peck]

Nom. for nsbeta, since 47463 was and this seems quite a bit worse than the key
bindings not working -- this makes the feature basically unusable.

Comment 2

[Charles Manske]

The UI and commands are firing correctly. The problem, if any is most likely
in Joe's code, but since he's very busy, beppe might want to have someone else
investigate. I know there are limits on how much smaller or larger you can 
change the text, which is why clicking on smaller over and over (or vice versa)
may seem to have no effect.

Comment 3

[Joe Francis]

akkana, big and small dont have an effect past certina sizes: the tags still go 
in, but nothing visual happens.  this is a layout limitation.

i need you to check and make sure that you get nested <big> tags, one for each 
click.  if you do, then this is not an editor issue and needs to go to layout.

Comment 4

[rubydoo123]

reassigning to layout

Comment 5

[Akkana Peck]

You're right.  We are getting nested <big> and <small> tags; layout just isn't
doing anything with them in a lot of cases.  Sigh.  I guess this bug should be
closed.

Comment 6

[Akkana Peck]

Oh, I didn't notice it had been reassigned to layout -- reopening since the
non-editor part of the bug is still there.  I'll attach a file showing font
sizes.  

Comment 7

[Akkana Peck]

Attachment: Test file showing various font sizes

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

How did this work in 4.x?  (I can't tell because 4.x on Linux doesn't work well
with xfsft so I end up with either bitmap fonts or fonts that don't scale at
all.)

Comment 9

[Akkana Peck]

It sucked in linux/4.x as well.  0, +1, and +2 were all the same size, but +3
was bigger, and so forth.

Comment 10

[Kevin McCluskey (gone)]

Dividing up claytons bugs to triage.

Comment 11

[Kevin McCluskey (gone)]

My guess is that we may be leaving it up to GTK to try and find the closest 
match to the font size we give it instead of determining what the next largest 
or smallest font is ourselves.

Reassigning to Waqar.

Marking nsbeta3-.

Comment 12

[waqar]

This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration.

Comment 13

[waqar]

Test case seems to be working with 01/24/2001 build