Open Bug 174216 Opened 22 years ago Updated 13 years ago

Some character entity references entered as html code are replaced with their corresponding characters in source view when tab is switched.

Categories

(SeaMonkey :: Composer, defect)

Product:
SeaMonkey
Component:
Composer
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: ozgur271, Unassigned)

References

(Blocks 1 open bug)

Details

In Composer of Mozilla 1.2a, when I edit source code manually, and add i.e. a mathematical beta symbol &#946; , i find it's replaced with the real beta symbol in source view when I switch tabs. Composer saves the html code as I entered but doesn't show exactly what it saves in source tab. If this is a feature I don't like it and want to have an option to turn it off. Steps to reproduce: 1) Enter this text to "<HTML> Source" tab of Composer between <body> tags: "This is a beta symbol: &#946;<br>" 2) Switch to "Normal" tab. You see: "This is a beta symbol: &#946;" 3) Switch to "<HTML> Source" tab again. You see: "This is a beta symbol: &#946;<br>" instead of what you've entered at step 1. 4) Save file and open with a text editor. You see: "This is a beta symbol: &#946;<br>"
WFM on MacOS 9.1 Build 2002100911
Correction to the description of bug: While pasting texts to description of the bug, some beta symbols I see on field are replaced with &#nnn; equivalents on web page. You're supposed to see actual beta symbols ( a character like B ) at reproduction steps 2 and 3 instead of #946; . Sorry for the error...
You are right i see a beta on step 2 and 3 If i enter &beta; i got the same problem. Curiously when i copy the beta symbol to the clipboard, and open the clipboard in the finder, it says that the clipboard contains unknown data. More curiously i can paste it in an aother text application. I don't know if it is an other idependant bug.
I have investigated about my remark about the clipboard. It is not a bug Some explanations for Mac Users: I found a way to see the data types that are in the clipboard For a normal text i have (including eacute): "TEXT", "MZ
The bug exists in "Linux i686; rv:1.2b Gecko/20021016" Composer.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
still happens in trunk/2002122308/win2k. probably the same bug, but a slightly different case, is if the file loaded contains the entity for a quote mark - &quot;. in that case, the source view shows a " symbol instead of the entity as with the original report here, but saving the file also saves the " symbol rather than the &quot; entity.
OS: Linux → All
reassign to new placeholder
Assignee: syd → composer
Status: ASSIGNED → NEW
Composer always changes character entities that are in the lower ASCII range to the character. That is, if I want to hide my email address from viruses that search the web cache by using &#64; instead of @, Composer will change it to the @ sign for me so that I cannot do this. I believe the specification at http://www.w3.org/TR/html4/types.html#type-cdata says that it is the user agent (not the editor) which is supposed to do this. It would be nice to have this fixed.
In Comment 8, Bruce Terry talked about how Composer saves entities in the format it desires instead of the format entered. I have just filed a seperate bug, Bug 200264 thta deals with that issue, since this bug is about how entities are displayed in Composer.
Blocks: 174361
*** Bug 231450 has been marked as a duplicate of this bug. ***
*** Bug 257401 has been marked as a duplicate of this bug. ***
*** Bug 225209 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
(In reply to comment #0) I am experiencing the same behavior, and it is very annoying. One would expect the source pane to show the actual source of all HTML markup, but some character entities and references are rendered as they would by the browser.
Same here but for German umlauts. Entering &amp;auml; (umlaut "a") in the html sourcecode will be translated directly into a single 'ä' with the current ISO charset (Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8b) Gecko/20050301)
*** Bug 202446 has been marked as a duplicate of this bug. ***
> Same here but for German umlauts. Entering &amp;auml; (umlaut "a") in the html > sourcecode will be translated directly into a single 'ä' with the current ISO > charset (Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8b) Gecko/20050301) Try this workaround. 1- Create a new plain text file 2- Edit in it this: user_pref("editor.encode_entity", "basic") 3- Name that file user.js 4- Save it into your profile. E.g. in XP: C:\Documents and Settings\[os-profile]\Application Data\Mozilla\Profiles\[Your Seamonkey Profile]\[bunch of numbers+letters.slt I tried it in Composer from Seamonkey 1.1a rv:1.9a1 build 2005092606 under XP Pro SP2 and it is working for German characters (ß ä ü). This will work for any characters in the iso-8859-1 plane from code position 128 (Ax) to 255 (Fx). See this character map http://en.wikipedia.org/wiki/ISO_8859-1#Code_table for the characters which will not be converted, will not be translated into characters entities (when switching back and forth from and to HTML source edition mode or any other edition mode) if and only if the document is created and then saved with iso-8859-1 (aka iso-Latin 1).
I've recently encountered this bug in SeaMonkey 1.1.4 Composer. Source code is not being shown for character entities such as &rArr;. Very annoying.
Assignee: composer → nobody
QA Contact: sujay → composer
Still here User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 SeaMonkey/2.13a1 Build identifier: 20120712003002
You need to log in before you can comment on or make changes to this bug.