nsRange::CreateContextualFragment doesn't produce a textnode for <title> contents




18 years ago
17 years ago


(Reporter: Charles Manske, Assigned: harishd)


({dataloss, relnote})

Windows NT
dataloss, relnote

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3-][PDTP1][Fix in hand][rtm++])


(3 attachments)



18 years ago
Supplying a string like this:
<head><title>My Page</title></head>
to CreateContextualFragment yields a nsDOMDocumentFragment with a 
nsHTMLTitleElement child node, but no textnode for the title contents.
In Composer, use View | HTML Source, then add a title tag
and contents in the source editor. Switch back to "Normal Edit Mode" and break
in nsHTMLEditor::ReplaceHeadContentsWithHTML(), nsHTMLEditor.cpp, to debug.
I'm no sure about component or who to assign to, but vidur knows about the issue
and will redirect.

Comment 1

18 years ago
BTY: This does not block Composer's HTML Source editing from working, so this
can be "futured".

Comment 2

18 years ago
In previous discussions with Vidur and RigkG, they seemed to know exactly 
what causes this problem and how to fix it. I have discovered another situation
which *does* impact greatly on composer: all <style> .... </style> 
and <script> ... </script> content in a Composer page will be lost after
using HTML Source editing.
This is not good!
Keywords: dataloss, nsbeta3

Comment 3

18 years ago
Re-assigning to Johnny.  Marking nsbeta3-.  Nominating for rtm because not 
fixing this is going to result in users lising script and style content in the 
head element when they edit it.
Assignee: vidur → jst
Keywords: rtm
Whiteboard: [nsbeta3-][egk]

Comment 4

18 years ago
Mass update of qa contact
QA Contact: gerardok → janc
cc:ing bijals. Bijal, if this bug isn't fixed, Composer will blow away the
SCRIPT and STYLE tags in the HEAD of every document it edits. Essentially, this
means that Composer can't be used to edit any document that uses JavaScript
(since that's usually in the HEAD) or CSS (since STYLE tags are required to be
in the HEAD).

This is serious user document data loss with no workaround, so marking P1 per
PDT priority definitions. Clearing [nsbeta3-] to trigger re-evaluation; I think
we cut too deep here.

P1 permits a fix with mozilla reviewers' permission as late as 9/21. Can we find
someone who has the time to fix this by 9/21?
Priority: P3 → P1
Whiteboard: [nsbeta3-][egk] → [egk]

Comment 6

18 years ago
Harish and Vidur are gonna work on this together.  marking nsbeta3+
Assignee: jst → harishd
Whiteboard: [egk] → [nsbeta3+]

Comment 7

18 years ago
PDT:  Either we get this fixed or consider removing html editing, the data 
corruption is too severe.  Agree, P1.  Not a ship stopper for PR3, though, we 
CAN release note this.
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP1]

Comment 8

18 years ago
I'm pretty close to a fix for this ( may be a day more ).

Comment 9

18 years ago
Created attachment 15176 [details] [diff] [review]
Proposed patch version 1.1.


18 years ago
Whiteboard: [nsbeta3+][PDTP1] → [nsbeta3+][PDTP1][Fix in hand]

Comment 10

18 years ago
Created attachment 15218 [details] [diff] [review]
patch version 1.2 ( includes support for textarea )


18 years ago
Whiteboard: [nsbeta3+][PDTP1][Fix in hand] → [nsbeta3+][PDTP1][Fix in hand][ETA 09/22/00 ]

Comment 11

18 years ago
Created attachment 15330 [details] [diff] [review]
Partch version 1.3

Comment 12

18 years ago
I've tested the patch and it works great.
The only problem I see is formatting of DOM source into HTML source
(doen's break after <meta...> like it should, and extra linefeeds are inserted
inside a <style> ... </style> tag.
but that's a different bug.

Comment 13

18 years ago
I saw the extra linefeeds too...but I'm almost sure that it has got nothing to
do with my change.

Comment 14

18 years ago
Patch version 1.3 has been r=jst & a=waterson. 

PDT, could you please ++ this bug? 
Whiteboard: [nsbeta3+][PDTP1][Fix in hand][ETA 09/22/00 ] → [nsbeta3+][PDTP1][Fix in hand]

Comment 15

18 years ago
Marking relnote and rtm+.  Harish will check in the fix to the trunk.  We will 
wait until after PR3 ship to check this fix into the branch.
Keywords: relnote
Whiteboard: [nsbeta3+][PDTP1][Fix in hand] → [nsbeta3+][PDTP1][Fix in hand][rtm+]

Comment 16

18 years ago
Marking nsbeta3- to get this off the beta 3 radar.
Whiteboard: [nsbeta3+][PDTP1][Fix in hand][rtm+] → [nsbeta3-][PDTP1][Fix in hand][rtm+]

Comment 17

18 years ago
Changes are in the trunk.

Comment 18

18 years ago
Why don't we want to checkin to the nsbeta branch now so this gets some 
testing before rtm?

Comment 19

18 years ago
Because the branch hasn't been tagged for PR3 yet.  We don't want this fix to go 
into beta 3, only rtm.


18 years ago
Blocks: 54283

Comment 20

18 years ago
PDT marking [rtm++]
Whiteboard: [nsbeta3-][PDTP1][Fix in hand][rtm+] → [nsbeta3-][PDTP1][Fix in hand][rtm++]

Comment 21

18 years ago
Fix is on the TRUNK too. Marking FIXED.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 22

18 years ago
*** Bug 49873 has been marked as a duplicate of this bug. ***

Comment 23

17 years ago
2000-11-08-01-MN6: Win32
You need to log in before you can comment on or make changes to this bug.