&nbsp removed from source when changing views

VERIFIED FIXED in mozilla0.9.3

Status

()

Core
Editor
P2
minor
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: Ariel Gonzalez, Assigned: anthonyd)

Tracking

Trunk
mozilla0.9.3
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [behavior][serializer][in trunk][not in 0.9.2 branch])

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9+) Gecko/20010513
BuildID:    2001051308

When in the Composer, if you add a few &nbsp's to your file using the source
view, then switch away from that view to any other (normal, tags or preview)
then switch back to source, the &nbsp is gone.

Reproducible: Always
Steps to Reproduce:
1. Enter some text into the Normal view
2. Switch to source view and insert a &nbsp somewhere in that line
3. Switch to any other view. Notice that it is "working"
4. Switch back to source view and notice that is gone

Actual Results:  keep the &nbsp's that I added in there

Expected Results:  &nbsp's are gone

The &nbsp will be removed anywhere in the source. Also, after noticing that the
nbsps are gone, if you switch back to normal view, it looks "weird". The cursor
is not right next to the character it is deleting, like there is a space between
the character and the cursor.

Of course, the workaround is do your main editing in the composer, then load the
page in notepad and add your &nbsp's.
Compositor != Composer. Changing component to Editor.
Assignee: kmcclusk → beppe
Component: Compositor → Editor
QA Contact: petersen → sujay

Comment 2

17 years ago
Also occurs on linux 2.4 build ID2001051621.  Note if after step 4 you save the
html file it saves with   in the correct places.

Comment 3

17 years ago
so, Phil are you saying that if you enter the nbsp, switch to source view and it 
looks like it is gone, that it really isn't gone? I'm confused by your comment 
on 5-17 at 15:00
(Reporter)

Comment 4

17 years ago
I did some more testing with saving the file (didn't try that one before, thank
you Phil!) and here is what i got.

The original is:
 test

If after Step3 I save the file, this is what I get saved:
 átest 

If I save after Step4, I get just two blank spaces before 'test'.
Hope this helps!

Comment 5

17 years ago
gee this is really strange, on win98 it doesn't matter when I save the file, I 
still retain the nbsp. In composer it displays as a space, but if I look at the 
file in notepad, the nbsp is there.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

17 years ago
I am really not sure who to give this one to, gonna start with joe and add a 
bunch of other folks
Assignee: beppe → jfrancis
Priority: -- → P2
Whiteboard: [behavior]
Target Milestone: --- → mozilla0.9.2

Comment 7

17 years ago
10 to 1 it's a serializer issue.  I wish we had an owner for this stuff.

Comment 8

17 years ago
need help with serializer stuff - i can't get to this anytime soon
Keywords: helpwanted

Comment 9

17 years ago
marking [serializer].  these bugs need to go to someone else.
Whiteboard: [behavior] → [behavior][serializer]

Comment 10

17 years ago
over to tony
Assignee: jfrancis → anthonyd
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 11

17 years ago
I bet what's happening here is that whatever is serializing the plaintext is
setting the flags wrong so that entities aren't being expanded to &; form, so
the source/plaintext editor is showing the character for nbsp (0xa0, IIRC)
rather than the expanded   form.

I think this used to work right.  Did the code to serialize to html while
switching to source mode change sometime before this bug was filed?

Anyway, check the flags on the serializer.

Comment 12

17 years ago
removing the nbsp can drastically alter the look of the web page, nbsp is the
only mechanism to preserve whitespace out of the pre

reviewed and approved
Keywords: helpwanted → nsBranch
(Assignee)

Comment 13

17 years ago
accepting and working on it.  following akkana's advice and trying to figure out 
who changed this since this is ar egression.

anthonyd
Status: NEW → ASSIGNED
(Assignee)

Comment 14

17 years ago
fixed, will attach the patch.
r = kin, gonna need a sr= from sfraser.
adding sfraser to the cc list

anthonyd
(Assignee)

Comment 15

17 years ago
Created attachment 42138 [details] [diff] [review]
patch for fix for this
(Assignee)

Comment 16

17 years ago
also, will need branch approval, this shouldnt be a problem since it is an easy 
fix and it is a serious bug (data corruption).

Comment 17

17 years ago
sr=sfraser
(Assignee)

Comment 18

17 years ago
checked into trunk, still awaiting branch checkin approval.
anthonyd

Updated

17 years ago
Whiteboard: [behavior][serializer] → [behavior][serializer][in trunk]
(Assignee)

Updated

17 years ago
Severity: normal → minor
Keywords: vtrunk
(Assignee)

Updated

17 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Whiteboard: [behavior][serializer][in trunk] → [behavior][serializer][in trunk][not in 0.9.2 branch]
(Assignee)

Comment 19

17 years ago
resolving this bug as fixed.

Comment 20

16 years ago
Verified in 8-27 build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.