Composer corrupts a HTML page with javascript (multiply embedded single and double quotes)

RESOLVED INCOMPLETE

Status

SeaMonkey
Composer
--
critical
RESOLVED INCOMPLETE
15 years ago
10 years ago

People

(Reporter: jean-max Reymond, Unassigned)

Tracking

({dataloss})

Trunk
dataloss

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021203
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021203

The display is not correct after inserting a blank

Reproducible: Always

Steps to Reproduce:
1.edit with composer http://jmreymond.free.fr/tommy/jobsbody.html
2.go in the <HTML source> tab and insert a blank in a blank line
3.return to the normal tab: you can see some piece of javascript

Actual Results:  
incorrect display

Comment 1

15 years ago
*** Bug 183540 has been marked as a duplicate of this bug. ***
"composer" == "editor:composer", not "editor:core"
Assignee: jfrancis → syd
Component: Editor: Core → Editor: Composer

Comment 3

15 years ago
confirming; I see this also when changing the html content (as opposed to
editing a script)--just type "abc" between the <br> tags
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dataloss, nsbeta1
OS: Windows 2000 → All
Hardware: PC → All

Comment 4

15 years ago
-->composer
Assignee: syd → composer

Comment 5

15 years ago
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
Workaround for reporter until we fix the bug: remove all occurences of &quot;
from attribute values. Example: &quot;service&quot;

I confirm the bug.

The reparsing of the html content chokes on this attribute, expanding it to
its character value and hence closing the attribute data.
The bug comes from our serializing of event handling attributes and
href/src when they contain a javascript: url. We don't escape entities
in the case of such attributes... See
http://lxr.mozilla.org/seamonkey/source/content/base/src/nsXMLContentSerializer.cpp#389

Comment 8

15 years ago
not all JS is being corrupted, it seems to be specific to this type of case:

<a onmouseover="jsFunc('<ul><li>..."service" and "results".</li>', event)"
   onmouseout="couic()"
   onclick="return false">
 text to be shown here 
</a>

Comment 9

15 years ago
btw bug 68167 still seems to be fixed

Comment 10

15 years ago
Composer triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
WFM with trunk build 20030428
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 12

15 years ago
reopening bug
I don't believe this is fixed.  The content at the url above has changed.
It now uses &quot; entity where it once had double-quote (").
Removing url (http://jmreymond.free.fr/tommy/jobsbody.html).

Please see comment 8 for a snippet of a still broken example.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: Composer corrupts a HTML page with javascript → Composer corrupts a HTML page with javascript (multiply embedded single and double quotes)
(Reporter)

Comment 13

15 years ago
the page http://jmreymond.free.fr/tommy/jobsbody.html has no changes since the
bug is opened.
Product: Browser → Seamonkey
No activity since November 2004, no comment since May 2003.
I don't use Composer myself so I cannot validly check this bug.
Is anyone still seeing it on SeaMonkey 2.0a1pre?
Unless someone replies within, say, a week or so I suppose this bug will be resolved INCOMPLETE or WORKSFORME.

Comment 15

10 years ago
Ten days gone, no reply, resolving as INCOMPLETE
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago10 years ago
Resolution: --- → INCOMPLETE

Comment 16

10 years ago
This is almost certainly still a bug but I don't have a recent Seamonkey build to test this against.  Why the rush to resolve an old bug?

Daniel--can you confirm (reopen bug)?
(In reply to comment #16)
> This is almost certainly still a bug but I don't have a recent Seamonkey build
> to test this against.  Why the rush to resolve an old bug?

An effort has been recently launched (by Kairo, the SeaMonkey Council head) to "decide" old Mozilla Suite bugs, decide whether or not they still apply to SeaMonkey, and update them accordingly. Would you rather these bugs should remain unresolved but unattended, forgotten, falling into oblivion? If it's still a bug, it should be Confirmed and if possible worked on; if it isn't, it should get Resolved and maybe even Verified.

> Daniel--can you confirm (reopen bug)?

See Daniel's comment #11.
You need to log in before you can comment on or make changes to this bug.