154139 - save reformats HTML when not supposed to (select/option) [retain original source formatting pref not honored]

Status: NEW

(Core :: DOM: Serializers, defect, P5)

Description

[Paul Lorenz]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020611
BuildID:    2002061104

Selected the "Retail Original source formatting" pref in composer. 
Had a select define in my HTML

<select>
  <option> ...</option>
   ...more options...
</select>

after I saved, this was converted to 

<select><option>...</option>...more options</select>

Not only does this formatting suck, but it wasn't supposed to format it at all
according to the pref. 

Reproducible: Always

Comment 1

[Bill Mason]

WFM in build 2002062308 PC/Win98.

If you create a new profile and try it there, does the problem persist?

Comment 2

[Paul Lorenz]

Created a new profile and tried it. Still reformatted after I set the pref not
to. Tried again after restarting moz. Same behavior. Note, I don't think it is
reformatting the same way it would if the pref is set. 

If I select the reformat option, add a space somewhere and save, it formats the
HTML fragment to

  <select>
  <option value="12">12</option>
  <option value="24">24</option>
  <option value="36">36</option>
  <option value="48">48</option>
  </select>

When I select the no format option, add a space and save, it immediately
converts the above to

<select><option value="12">12</option><option value="24">24</option><option
value="36">36</option><option value="48">48</option></select>

It seems like the no format option is really more like unformat :)

Comment 3

[Kathleen :Brade]

Is the preference/checkbox set backwards?  Does it reformat select/option tags
if you don't have the pref/checkbox set?

Could you get a newer version of mozilla and test that?  Perhaps this issue was
already fixed in the last few weeks?

Comment 4

[Chad Mallory]

It reformats the text if the checkbox is checked AND when it is not checked.

It was not fixed as of 07/07/02.

Comment 5

[Paul Lorenz]

> Is the preference/checkbox set backwards?  Does it reformat select/option tags
> if you don't have the pref/checkbox set?

There are two radio buttons, one for "Retain original source formatting" and one
for "Reformat Source Code". Each formats the HTML, but in different ways. 

> Could you get a newer version of mozilla and test that?  Perhaps this issue was
> already fixed in the last few weeks?

I will update the bug report as soon as the 1.1beta is released, which should be
soon, as (according the roadmap) the freeze date is today.

Comment 6

[Kathleen :Brade]

-->DOM to Text Conversion

Comment 7

[Paul Lorenz]

Verified with Mozilla 1.1beta. This time I just used the html for a blank
screen. I saved with Reformat then saved with do not reformat. The second save
should have been the same as the first. It was not.

Comment 8

[Thomas]

Last action was 2002-07-23 with Mozilla 1.1beta.
Is this bug reproducable with Mozilla 1.7 (or Nvu)?

Comment 9

[Stephen Hind]

Yes this is reproducable with Mozilla 1.7.2 (Mozilla/5.0 (X11; U; Linux i686;
en-GB; rv:1.7.2) Gecko/20040804)

I always code using XHTML so for meta tags, for instance, you need to use /> to
close the tag.  Both Mozilla and Firefox remove the / and retain the >: this
makes tha saved page invalid XHTML.  This happens for either setting of the
"Retain Original Source Formatting"/Reformat HTML Source" radio button.

Comment 10

[Akkana Peck]

Stephen: Reformat concerns whitespace and newlines in the saved html source. 
For saving as xhtml, you want bug 45628.

Comment 11

[Stephen Hind]

Sorry, you've missed my point: when I save a Validated XHTML Page Mozilla
reformats the page so it no longer validates.

If Mozilla decides to add a feature to reformat a page into XHTML that that's
great and very useful: my problem still stands - when I save a page I expect it
to still validate if it did previously.

Why does Mozilla chage the tags? It's unnecessary to do so, and de-grades the page.

I should have reported this ages ago as it's always been the case.

Comment 12

[Thomas]

reading comment #11, someone should change this bug status to "new".

Comment 13

[timeless]

[e-mail]: no, as akkana said, this bug is not about xhtml.

it's very much about *whitespace*. i'm most certainly not going to confirm it
based on that.

[e-mail]: i hope you've found a closer match. note that mozilla
composer doesn't claim to support xml or xhtml, so your bug would be an enhancement.

Comment 14

[Stephen Hind]

(In reply to comment #13)
> [e-mail]: no, as akkana said, this bug is not about xhtml.
> 
> it's very much about *whitespace*. i'm most certainly not going to confirm it
> based on that.
> 
> [e-mail]: i hope you've found a closer match. note that mozilla
> composer doesn't claim to support xml or xhtml, so your bug would be an
enhancement.

No it's a bug, look at it this way: You take a W3C Validated webpage and save it
using Mozilla - the saved page no longer validates!  How is this an enhancement?
 You want Mozilla to give an indentical, which it doesn't.

Comment 15

[Kathleen :Brade]

Although this bug was created with a comment describing the problem using
Composer, the bug is not an editor bug.  It is correctly targeted to DOM to text
conversion.  The browser will have this bug.  Composer will have this bug.  Mail
has this bug (though I think they strip the doctype so it wouldn't be easy to
get it to reproduce it there).

This bug does describe a problem with a composer pref not being honored.  It is
also specific to <SELECT> and <OPTION>.  The original bug description and
subsequent followups make no mention of XHTML or /> issues.

Comment 16

[Steuard Jensen]

(In reply to comment #15)
> Although this bug was created with a comment describing the problem using
> Composer, the bug is not an editor bug.  It is correctly targeted to DOM to
> text conversion.  The browser will have this bug.
[snip]

With that in mind, is this related to bug #118248?  It sounds like very much the
same problem: whitespace is changed, and I have recently observed that "Save as
Web Page, complete" in Firefox 1.0 Mac also removes XHTML '/'s just as described
(for Composer) in comment #9 above.  (That's XHTML served as "text/html", of
course; XHTML served as "application/xhtml+xml" doesn't give the "Web Page,
complete" option for some reason.)

As I understand it, in comment #13 [e-mail] claims that the
whitespace issue is distinct from the "deleting '/'" issue.  I don't know the
underlying implementation, and the two problems may in fact be technically
unrelated.  But I agree with the subsequent comments which insist that if
Mozilla deletes _anything_ from the document as typed, it is not "retain[ing]
original source formatting", whether it's deleting whitespace, '/', or anything
else.

(I guess that the term "formatting" might technically apply only to whitespace,
in which case [e-mail] is right.  But then what should one call it
when Composer deletes actual typed content?  It sounds like this could approach
"dataloss", depending on just how many things get silently dropped this way and
how important those '/'s are considered to be.)

Comment 17

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 18

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.