Bigger and Smaller don't work most of the time

RESOLVED WORKSFORME

Status

()

Core
Layout
P3
normal
RESOLVED WORKSFORME
18 years ago
17 years ago

People

(Reporter: Akkana Peck, Assigned: waqar)

Tracking

Trunk
Future
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-])

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
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.
Keywords: 4xp, nsbeta3

Comment 2

18 years ago
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.
Assignee: cmanske → jfrancis

Comment 3

18 years ago
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

18 years ago
reassigning to layout
Assignee: jfrancis → clayton
Component: Editor → Layout
QA Contact: sujay → petersen
(Reporter)

Comment 5

18 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 6

18 years ago
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.  
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 7

18 years ago
Created attachment 13380 [details]
Test file showing various font sizes
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.)
(Reporter)

Comment 9

18 years ago
It sucked in linux/4.x as well.  0, +1, and +2 were all the same size, but +3
was bigger, and so forth.
Dividing up claytons bugs to triage.
Assignee: clayton → kmcclusk
Status: REOPENED → NEW
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-.
Assignee: kmcclusk → waqar
Whiteboard: [nsbeta3-]
(Assignee)

Comment 12

18 years ago
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.
Target Milestone: --- → Future
(Assignee)

Comment 13

17 years ago
Test case seems to be working with 01/24/2001 build
Status: NEW → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.