Closed Bug 98775 Opened 23 years ago Closed 14 years ago

Paragraph style does not properly display after choosing a type and inserting a table or H. rule

Categories

(SeaMonkey :: Composer, defect)

Product:
SeaMonkey
Component:
Composer
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: TucsonTester2, Unassigned)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3+) Gecko/20010903
Netscape6/6.1b1
BuildID:    20010903

In the composer window before I added anything to the window I chose a paragraph
style, heading 1 for example, then I inserted a horizontal rule.  After
inserting the horizontal and putting the cursor on the line below and typing
text, the paragraph style still showed that it was heading 1.  This happened all
the way down the page as I typed.

Reproducible: Always
Steps to Reproduce:
1.Open Composer
2.Change the paragraph style to heading 1
3.Insert a horizontal rule using the H.line button on the toolbar
4.Place the cursor below the H.line

Actual Results:  The paragraph style will indicate that it is Heading 1.  If you
switch to the HTML Source you will see that the heading 1 tag is no where to be
found, even where you first tell the page to have the heading one style.

Expected Results:  I would expect that the paragraph style would display properly.
Sorry, wrong steps to reproduce.  These are the correct ones
Steps to Reproduce:
1.Open Composer
2.Insert a horizontal rule using the H.line button on the toolbar
3.Highlight the horizontal rule and change the paragraph style to heading 1
4.Place the cursor below the H.line (If you hit enter and type text it will
always be heading 1)
Confirmed in 9-10 build
Status: UNCONFIRMED → NEW
Ever confirmed: true
I have found another way to reproduce this using the 20010924 build on Mac OSX,
but I have seen this reproduce on Win 2k.

Reproducibility: everytime

Steps to reproduce:
1.Open composer
2.Click on the indent button on the toolbar
3.Type in some text
4.Change the paragraph style to Heading 1 using the paragraph drop-down menu on
the toolbar
5.Click on Edit -> Undo

Actual Results:
The paragraph style will not update.  The only way to get it to update is to
click on the outedent button on the toolbar. Once the blockquote is removed the
paragraph style will update.

Expected Results:
I would expect that the paragraph drop-down would reflect the change that I made
-->core; I can't reproduce on trunk build on Mac OS 9.1
Assignee: brade → kin
I can reproduce this on the Trunk.

This is a composer problem. In particular the nsInterfaceState code broadcasts a 
"undo" event during an undo and redo and the commandset code in 
editorOverlay.xul isn't listening for it.

This may be as simple as adding the "undo" to the list of events supported by 
the commandsets in editorOverlay.xul, but I'm reassigning it back to composer 
group, just in case they find they need to refactor out some of the commandsets 
to prevent unnecessary updating of some commands.
Assignee: kin → brade
Component: Editor: Core → Editor: Composer
I have found this issue does reproduce using the 20011015 build on XP.  Another 
note is that the error also occurs when using a table as opposed to the H. line.

1.Open Composer
2.Insert a 2x2 table using the table button on the toolbar
3.Highlight the table and change the paragraph style to heading 1
4.Place the cursor below the table (If you hit enter and type text it will
always be heading 1)
-->cmanske for triage (should this be EDITORBASE?)
Assignee: brade → cmanske
Since we normally automatically end heading styles when enter/return is used,
I would expect that to still work for the cases described here. The key factor
in this bug seems to be when the heading style is applied to non-text nodes,
the normal rules code isn't working correctly.
I'm a bit ambivalent about calling it EDITORBASE, but am marking as such so Joe
can give it some attention asap.
Assignee: cmanske → jfrancis
Whiteboard: EDITORBASE
Charlie, I'm confused.  Kin's comments make me think that we need composerCommand 
work here.  Do you want me to do that?  I'm not very familiar with it but I could 
try.

Kin, I don't see the connection between the steps used to duplicate this bug,
and the "undo" event. What is this undo event, and under what circumstances does
it get generated? Taking this bug so I can learn something.
Assignee: jfrancis → syd
actually, there must be something we need to listen for, or check the return of,
in this context. My guess is that the backend code is not applying the heading
style to the hr, which, to me, actually kinda makes sense (I can't make it bold
either, and the text around the hr after I try does not go bold).

So, if this is the case, is it valid to make buttons like bold, or the text
style menu, or the ol and ul buttons (which don't work right either in this
context) selectable? Maybe we should be "listending" for the current selection,
and deciding if we should disable certain items in the UI so that users can't
try and do things that are ill-defined, not to mention simplify things a bit. 
To answer Syd's question, I mentioned "undo" because I looked into the scenario
specified in comment #3 above.

For the original reported problem, we don't wrap the HR with a block element
because it looks like a block element to the HTMLEditRules code, so nothing gets
done and no error is thrown. Note that we don't throw an error because while
iterating over the contents of the selection, we purposely skip over items in
the selection that we can't wrap with blocks.

In any case, after the command is executed and nothing is done, the command
updating code should kick in and sync the UI with the backend, that is switch
the menu from "h1" back to "body", except that there is an optimization in
nsMultiStateCommand::UpdateCommandState() that only triggers ui updating when
curFormat != mStateString.
the steps seem unlikely, so we are marking EDITORBASE-
Whiteboard: EDITORBASE → EDITORBASE-
Status: NEW → ASSIGNED
I vote for gving this to Charlie, and having him make the two changes Kin
suggests (perhaps they are made already?).
1) Composer should listen for undo event and update state
2) Composer should refresh state even if curFormat == mStateString

assigning to Charlie.
Assignee: syd → cmanske
Status: ASSIGNED → NEW
remove editorbase- since this is not a core editor issue
Whiteboard: EDITORBASE-
Product: Browser → Seamonkey
Assignee: cmanske → nobody
QA Contact: sujay → composer
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.