If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Clicking on Bold icon does not accurately reflect selection setting

VERIFIED FIXED in M15

Status

()

Core
Editor
P3
normal
VERIFIED FIXED
18 years ago
16 years ago

People

(Reporter: bijals (gone), Assigned: Simon Fraser)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT-])

(Reporter)

Description

18 years ago
Steps:
1) Launch Editor by choosing Editor option in Task menu
2) Click on anywhere on the bold "html" text and notice change in Bold icon
state
3) Double click on text "testing" to select the whole word and notice the Bold
icon is not active
4) Click the Bold icon once and notice that the text "testing" is not bold
5) Move the mouse away from the Bold icon and notice that the state says that
the selected "testing" text is not bold even though it is
6) Undo the selection on the text "testing" by clicking on the text to place
cursor some where in side the word and notice that the Bold icon says that the
text is not bold when it is

Actual Results: Bold icon does not reflect actual text property

Expected: Bold icon states should change when bolding is applied or removed

Build 1999091608 on NT

Updated

18 years ago
Assignee: buster → sfraser

Comment 1

18 years ago
sounds like bold is working correctly, but the button is not reflecting that
fact.  Could it be that the selection is outside the boundary of the bold, and
we have to be smarter when we query for the property?
         <P>
    T0   <B>  T2
    'a'  T1   'c'
         'b'

in this simple content model, we can represent a selection of "b" by
Sel((T1,0), (T1,1))
or
Sel((T0,1), (T2,0))
we should report either as bold from nsIHTMLEditor::GetInlineProperty().
Maybe nsHTMLEditor::GetInlineProperty() has to be smart enough to account for
selection at the boundaries and treat the selection as the tightest legal
selection that encompasses the same content?

OR, is the button code just wrong?
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M12
(Assignee)

Comment 2

18 years ago
No, I think this is a problem with widgets. On Mac, the bold button works
correctly. On Unix and Windows, it does not. I have no idea what could cause this
difference in behaviour, but it is reliable. I'll take a look.

Comment 3

18 years ago
I notice that now the text attribute state is set correctly (in Windows) when
there is a selection, but not if you simply click (collapsed selectio/caret)
in some text that has a particular attribute.

Comment 4

18 years ago
on win95 using build 1999111108, I still see this problem. If I select within a
formatted area (B|I|U) the format toolbar does not indicate the correct state.
And the other issues that bijal mentions are still there.
(Assignee)

Updated

18 years ago
Target Milestone: M12 → M13
(Assignee)

Comment 5

18 years ago
M13

Updated

18 years ago
Target Milestone: M13 → M14

Comment 6

18 years ago
moving to m14

Comment 7

18 years ago
the bug charlie mentions (bad inline style feedback with collapsed selection) is 
cross-platform, and I know what's wrong there.  I've broken this out as a 
seperate bug: 24574, assigned to me.
(Reporter)

Updated

18 years ago
Keywords: beta1

Comment 8

18 years ago
far as we can tell, things pretty much work except icon state does not reflect 
change....seems ok for beta1
Whiteboard: [PDT-]

Updated

18 years ago
Target Milestone: M14 → M15
(Assignee)

Comment 9

18 years ago
This works now.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 10

18 years ago
verified in 2/28 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.