Selecting "Body Text" doesn't change style if in <pre> text that has <br>

VERIFIED FIXED in mozilla0.9.5



18 years ago
17 years ago


(Reporter: gtr, Assigned: mozeditor)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [behavior] fix in hand; need r=,sr=)


(1 attachment)



18 years ago
I did this sequence:

1. Entered text into composer as "body text" (=paragraph element, presumably).

2. Selected the text and changed to the "preformat" type.

3. Started new text element by pressing return twice; got fixed-width type,
presumed to be another <pre>...</pre> element.

4. Tried to change to "body text" from the element type menu by putting the text
cursor in the element and then selecting "body text" from the selection box;
this changed nothing in the composer window.

5. Tried to change to variable-width type using the Format->Font menu; this was
already set to "Variable width" although the type wasn't.  Further, changing it
to fixed-width type and then back to variable-width type didn't change this
display in composer.

6. Pressed the browse button; the browser window shows the text in the same form
as the composer window.

Comment 1

18 years ago
over to Editor
Assignee: asa → beppe
Component: Browser-General → Editor
QA Contact: doronr → sujay

Comment 2

18 years ago
charley -- this is probably a dup of your other font bug, but I thought I 
wouldlet you decide
Assignee: beppe → cmanske
Ever confirmed: true

Comment 3

18 years ago
Good bug. First though, use the "HTML Source" from the "View" menu to see
exactly what the HTML is so you don't have to "presume" what it is!
E.g., the "Body Text" is not in a <p>, but is plain text directly under <body>.
To get a <p> container, select "Paragraph" from the toolbar dropdown or menu.
Also, when you use Enter key, it does not generate another <pre> (or other
paragraph/container tag such as <p> if you are using that), but instead inserts
<br>. There's lot's of controversy about doing that, but let's not go into that
When you are in <pref>, using the font or other HTML attributes such as
bold, italics, etc., are ignored. (Maybe we should gray out UI for irrelevant
styles in that state?)
But the real bug you found is that once we are in <pref>, selecting
"Body Text" or "Paragraph" doesn *not* terminate the <pre> like it should.
Note that selecting other styles such as 'Paragraph, 'Address' or any 'Heading'
style does change <pre> into the appropriate style. Once you do that, changing
the font works correctly.
Joe: Do you know about this problem?
Hardware: Sun → All
Summary: Composer can't revert to variable-width type → Selecting "Body Text" doesn't change style if in <pre> text.
Target Milestone: --- → mozilla0.9

Comment 4

18 years ago
After investigating some more, the problem occurs only if you use Enter to insert
<br> inside the <pre>. After that, setting to "Body Text" fails because in
nsHTMLEditRules::ApplyBlockStyle(), the loop to get all the node types returns
<br> instead of <pre>, so it doesn't think it needs to change any style.
I suspect this is another special case of the more general problem with setting
style when <br>s are used (I know things like setting outdent enable state is
affected in a similar manner: bug 54218).
Assignee: cmanske → jfrancis
Summary: Selecting "Body Text" doesn't change style if in <pre> text. → Selecting "Body Text" doesn't change style if in <pre> text that has <br>

Comment 5

18 years ago
appeasing bug gods
Target Milestone: mozilla0.9 → mozilla0.9.1


18 years ago


18 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 6

18 years ago
this also happens when you do copy/paste and the paste is wrapped in a pre -- 
the pre seems to not want to get deleted
Keywords: correctness
Whiteboard: [behavior]

Comment 7

18 years ago
Created attachment 38731 [details] [diff] [review]
patch for editor/base

Comment 8

18 years ago
fixed by attached patch.  this patch includes and supercedes patch in 54539. 
This fix depends on that one.
Whiteboard: [behavior] → [behavior] fix in hand, need r=,sr=

Comment 9

18 years ago
r=fm; sr=kin; need a=
Whiteboard: [behavior] fix in hand, need r=,sr= → [behavior] fix in hand, need a=
a=blizzard on behalf of drivers for the trunk

Comment 11

18 years ago
fix checked in
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 12

18 years ago
Guy, is thsi fixed for you now in latest build?


Comment 13

18 years ago
I'm afraid this is *not* fixed in Solaris build 2001062622. The observed results
are exactly as in the original report.  However, using inside information, I now
know that if I select what look like the last two elements in the doc - i.e. two
single lines of fixed-width type separated by a vertical space, looking like to
sucessive <pre> elements, *then* I can change them both to "body text" and get
variable-spaced type.

This is what the end of the HTML,msource looks like:


The <br><br> construct, which I didn't ask for in the first place, looks like a
</pre><pre> construct and confuses matters.

If I now press return then use the menu to change to "body text, then I end up
in a new line of the last <pre> and with fixed-with type, but with the
element-type indicator showing "body text" and the Format->Font menu-item
showing variable-width type, which is wrong.  If, instead, I change from
preformat to paragraph, then I get a real <p>...</p> construct (with gratuitous
<br> at the end) and variable-width type.

Comment 14

18 years ago
based on comments above, reopening
Resolution: FIXED → ---

Comment 15

18 years ago
this must be fixed

reviewed and approved
Keywords: nsBranch
Whiteboard: [behavior] fix in hand, need a= → [behavior]
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 16

18 years ago
only a problem now if you are on an empty line.  I'll look into this.

Comment 17

18 years ago
see patch for this and other bugs attached to
bug 83918


18 years ago
Whiteboard: [behavior] → [behavior] fix in hand; need r=,sr=

Comment 18

18 years ago
Missed 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 19

17 years ago
clearing the nsbranch keyword so as not to be confused with the current set of 
nsbranch bugs.
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 20

17 years ago
really removing the keyword
Keywords: nsBranch

Comment 21

17 years ago
fix checked in
Last Resolved: 18 years ago17 years ago
Resolution: --- → FIXED

Comment 22

17 years ago
Guy, now is this fixed for you? try in recent build...thanks. let us know.

Comment 23

17 years ago
Following original steps, this looks fixed to me.  I am verifying since this has
been in Resolved Fixed for over a month.  

Original reporter, if you are still seeing this problem, please reopen this bug.

Verified on build 2001111303.
You need to log in before you can comment on or make changes to this bug.