Closed Bug 62347 Opened 24 years ago Closed 24 years ago

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

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Platform:
All
Solaris
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: gtr, Assigned: mozeditor)

Details

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

Attachments

(1 file)

patch for editor/base
29.90 KB, patch
Details | Diff | Splinter Review
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.
over to Editor
Assignee: asa → beppe
Component: Browser-General → Editor
QA Contact: doronr → sujay
charley -- this is probably a dup of your other font bug, but I thought I wouldlet you decide
Assignee: beppe → cmanske
Status: UNCONFIRMED → NEW
Ever confirmed: true
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 here. 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?
Status: NEW → ASSIGNED
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
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
Status: ASSIGNED → NEW
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>
appeasing bug gods
Target Milestone: mozilla0.9 → mozilla0.9.1
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla0.9.2
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]
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=
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
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Guy, is thsi fixed for you now in latest build? thanks.
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: <pre>qwer</pre> <pre>qwr</pre> <pre>qwr<br><br>werwqerqwrqwrwqerqwerwerwqe<br></pre> 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.
based on comments above, reopening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
only a problem now if you are on an empty line. I'll look into this.
see patch for this and other bugs attached to bug 83918
Whiteboard: [behavior] → [behavior] fix in hand; need r=,sr=
Missed 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
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
really removing the keyword
Keywords: nsBranch
fix checked in
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Guy, now is this fixed for you? try in recent build...thanks. let us know.
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: