Bug 16065 – WebKit applies the default style for removeFormat inappropriately

• Status: RESOLVED
• Resolution: FIXED
• Component: HTML Editing

[Anders Jenbo]

Calling execCommand('unformat', falce, null) on text in a headline will result in that content being formated with a span to match the default font, but that might not look right depending on the style sheet and is not what the user expects.

test case:
<h3>test</h3>
result:
<h3><span style="font-size: 16px; font-weight: normal;">test</span></h3>
should be:
test

[Anders Jenbo]

falce = false (typeo)

[Mark Rowe (bdash)]

A test case would be very helpful to demonstrate the issue here.

[Anders Jenbo]

I don't have time to write a good test case so you will have to make do with this.
http://jof.dk/rtef/gui/interactive/demo.htm
Go to format->h#, select all or some text, press Unformat (button #2), switch to HTML mode.
note: unformat in this RTE also calles JustifyNone

[Robert Blaut]

I can confirm the issue in the latest Webkit r31114 on Mac OS X 10.5

Steps to reproduce:

1) Go to http://jof.dk/rtef/gui/interactive/demo.htm
2) Type "test"
3) Choose menu Format -> Heading 3
4) Mark the word "test"
5) Click second button "unformat"
6) Click switch to HTML mode

Expected result:

test

Current result:

<h3 style="text-align: left;"><span style="font-size: 16px; font-weight: normal;">test</span></h3>

[Anders Jenbo]

A more permanent url to test with

http://rtef.info/demo.htm

[Ryosuke Niwa]

This does not reproduce on TOT.  Could you check it?

[Ryosuke Niwa]

I'm not what the original author meant by execCommand('unformat'...)  but if you meant removeFormat, it still reproduced on TOT.

[Ryosuke Niwa]

Created attachment 35007 [details]
demonstrates the bug

[Ryosuke Niwa]

I'm not sure what is the correct behavior here since Firefox ignores removeFormat.  Need to see what MSIE does.

[Anders Jenbo]

I have noticed this issue becoming even wheres in recent versions of safari, now just about Amy CSS roule is being aplyed to All elements with safaris efault values, even a lot of none standard css that safari uses.
Is TOT the latest build or something?


By the Way i just Got my hands ón an iPhone and i have noticed that it reports that it supports design mode, it has no means og eduting or selecting the content so this should probably be turned of so not to leave the uset with a non functional input and (the editor would fallback to a textarea input).

[Anders Jenbo]

(In reply to comment #9)
> I'm not sure what is the correct behavior here since Firefox ignores
> removeFormat.  Need to see what MSIE does.

The correct thing to do is remove any css or styling tags from the selected content, in the latest version safari removes all styling, all images and converts all spaces to  , in 3.x spaces where left alone.

Firefox doen't ignore the command.

original html:
<span style="font-weight: bold;">here's</span> the "<em>preloaded</em> <b>content</b>" <img src="cutegirl.jpg" alt=" />

Firefox:
here's the "preloaded content" <img src="cutegirl.jpg" alt=" />

MSIE (IE doesn't handle CSS styling):
<span style="font-weight: bold">here's</span> the "preloaded content" <img src="cutegirl.jpg" alt=" />

Safari 4.0.2 (Ouch my spaces):
here's&nbsp;the&nbsp;"preloaded&nbsp;content"

[Anders Jenbo]

By the way   is not the same as " ".

NBSP is char 00A0 and space is 0020, NBSP will not wrap on long lines (NBSP
stands for "none breakble space"), so it is effectivly like setting the content
to white-space:nowrap.

[Ryosuke Niwa]

(In reply to comment #11)
> The correct thing to do is remove any css or styling tags from the selected
> content, in the latest version safari removes all styling, all images and
> converts all spaces to  , in 3.x spaces where left alone.

There is a separate bug that states that removeFormat would delete image:
https://bugs.webkit.org/show_bug.cgi?id=17926

This bug should only be addressing the issue with h* tags since the original
bug report mentions about h3 tag.

That said, I'm not sure whether we should remove h* tags, ignore removeFormat
(what Firefox does), or add style-span to remove format.  Because h* tags are
not presentational, removing them change the semantics of the content.  But
Firefox does provide execCommand('heading'..) so its seems a bit odd that it
doesn't support removing h* tags.  I think it's probably safe to remove it but
need more research on this.

[Anders Jenbo]

Created attachment 35056 [details]
Samples of how safari and othere browsers handle the unformat command on some code from apple.com

Here is a more extensive sample of what is going on.

The code for this sample was taken from http://www.apple.com/macosx/ using copy and past in safari. Note that Safari decides to use an illegal <span> around the content to set the font etc. After executing the unformat command, the <h3> is now enveloping all the content, a <font> and <span> has been added inside to counter this, but the <span> misses the fist list item, leaving the first two lines bolted.

Notice how safari still adds <span style="font-weight: normal;"> around one of the lines.
It also seams to fail to remove the formatting from the empty span tag in the beginning plus a lot of the styling on the <h3> and <ul> tags, also an empty <ul> is illegal. All links have also been striped.

I have also included results from IE 8 and FF 3.5.2 for comparison, note that they are not perfect either.

IE doesn't handle css so all of that is piratically left alone.

FF gets close, but still leaves a chunk of style on every element.

lastly is a expected case.

[Anders Jenbo]

(In reply to comment #13)
> (In reply to comment #11)
> > The correct thing to do is remove any css or styling tags from the selected
> > content, in the latest version safari removes all styling, all images and
> > converts all spaces to  , in 3.x spaces where left alone.
> There is a separate bug that states that removeFormat would delete image:
> https://bugs.webkit.org/show_bug.cgi?id=17926
> This bug should only be addressing the issue with h* tags since the original
> bug report mentions about h3 tag.
> That said, I'm not sure whether we should remove h* tags, ignore removeFormat
> (what Firefox does), or add style-span to remove format.  Because h* tags are
> not presentational, removing them change the semantics of the content.  But
> Firefox does provide execCommand('heading'..) so its seems a bit odd that it
> doesn't support removing h* tags.  I think it's probably safe to remove it but
> need more research on this.

I think you are right in keeping <h3>, firefox does have a command to remove h3's it's called FormatBlock and will change them in to <p>'s

This bug was not meant to be exclusively about headings but about the general habit of safari applying it's default styling to every thing when unformating.

[Ryosuke Niwa]

(In reply to comment #15)
> I think you are right in keeping <h3>, firefox does have a command to remove
> h3's it's called FormatBlock and will change them in to <p>'s
> 
> This bug was not meant to be exclusively about headings but about the general
> habit of safari applying it's default styling to every thing when unformating.

Ok, the bug renamed.

[Ryosuke Niwa]

You need to file a bug for each one.  You cannot address all sort of issues in one bug.

(In reply to comment #14)
> The code for this sample was taken from http://www.apple.com/macosx/ using copy
> and past in safari. Note that Safari decides to use an illegal <span> around
> the content to set the font etc.

There is a bug filed for this.
https://bugs.webkit.org/show_bug.cgi?id=26937

>After executing the unformat command, the <h3>
> is now enveloping all the content, a <font> and <span> has been added inside to
> counter this,

This is a separate issue, which I thought you were addressing in this bug initially.  You should file another bug for this one.

>but the <span> misses the fist list item, leaving the first two
> lines bolted.
> Notice how safari still adds <span style="font-weight: normal;"> around one of
> the lines.

This is yet another bug.  Prepare a reduction and file a bug.

> It also seams to fail to remove the formatting from the empty span tag in the
> beginning plus a lot of the styling on the <h3> and <ul> tags, also an empty
> <ul> is illegal. All links have also been striped.

A lot of styling on h3 or ul isn't so definite.  Please be more specific about what is expected and what actually happens.  And you need to do it for much simpler HTML.

In general, we'd like to split the issues into smaller well-defined pieces.  For example, instead of saying WebKit doesn't remove format properly, say that WebKit adds style span when deleting h3, WebKit does not unbold all list when~~~.  Being specific helps other contributers to understand what your expectations are and what is wrong about current behavior.

I really appreciate your taking time to report the bugs because it helps us improving WebKit.  But please re-read https://webkit.org/quality/bugwriting.html and file each bug separately.

[Ryosuke Niwa]

This bug is no longer valid as WebKit not does not add any default styles when removing header elements (h1-h6) since http://trac.webkit.org/changeset/70283.  We don't remove h1-h6 elements either but this is consistent with other browsers.