Ticket #1298 (closed defect: fixed)

Opened 1 year ago

Last modified 1 year ago

CSS styling gets inserted into table cell after viewing source (Safari only)

Reported by: nicholasbs Owned by:
Priority: normal Milestone: 0.96
Component: Browsers_Safari Version: trunk
Severity: normal Keywords:
Cc:

Description

To reproduce:

1. Click "Insert Table" and then click "OK" to insert a table.
2. Click in one of the table's cells.
3. Click "Toggle HTML Source" twice.

There will now be CSS styling information in place of one of the cells. This happens in Safari 3.1.2, but not in IE7 or FF3.

Change History

Changed 1 year ago by nicholasbs

I've looked into this issue and think I found the source of the problem. There's a regex in the setCC function that seems off to me. Line 745 in Webkit.js currently reads:

ta.value = ta.value.replace(new RegExp ('(&[^'+cc+']*?)('+cc+')([^'+cc+']*?;)'), "$1$3$2");

I believe this regex is supposed to move the control character outside of an HTML character entity (e.g.,  ). However, the regex is too liberal, as it will greedily keep going past the control character. E.g., it will match

&amp;<a style="color: red;" href="http://www.example.com">foo</a>

all the way to the semicolon after 'red', assuming of course that the cursor (and thus the control character) is placed between the ampersand and the opening angle bracket. This is a simplified case of the issue reported above, since placing the cursor in the table cell means setting the control character just after a &nbsp;.

The solution is to simply not match internal semicolons, changing the regex to:

ta.value = ta.value.replace(new RegExp ('(&[^'+cc+';]*?)('+cc+')([^'+cc+']*?;)'), "$1$3$2");

What I'm confused by is that even though their respective modules use the same regex, neither Firefox nor IE are affected by this bug. Anyone know why this might be? I've diff'd the version of setCC and findCC in Gecko.js and WebKit.js, and they're practically identical.

Changed 1 year ago by nicholasbs

  • status changed from new to closed
  • resolution set to fixed

I've checked this change in for WebKit?.js as r1146.

I have not yet made the same change to the identical regexes for the Gecko and IE modules, since I would like to first figure out why it is that neither of them suffer from this same problem even though they have the same faulty regex.

Note: See TracTickets for help on using tickets.