[webkit-dev] DOM Mutation Event compatibility.

David D. Kilzer ddkilzer at kilzer.net
Tue Jul 3 10:06:17 PDT 2007


Please file bugs on http://bugs.webkit.org/ for each individual issue, even if
you're not sure it's a bug.

Reduced test cases for each bug (that fail on Safari/WebKit but work on MSIE or
Firefox) would help a lot!  Please attach the test cases as HTML files rather
than pasting the HTML in a comment.

Thanks!

Dave


Kalle Alm <kalle.alm at gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello folks,
> 
> In the process of making SynchroEdit compatible with Safari 3, we have
> done some profiling in regards to DOM Mutation Events, comparing these
> between Safari 3 and Firefox 2, in order to detect compatibility issues,
> general bugs, and potential workarounds. The following URL contains the
> report in question:
> 
> http://xprofiler.synchroedit.com/mutation-events/firefox-safari.html
> 
> Disclaimer: The issues here may or may not be bugs. The issues have not
> been thoroughly examined, but stem from the initial profiling report
> which can be found above. The issues may be bugs in SynchroEdit or in
> Firefox AND SynchroEdit or in all 3 (Safari, Firefox, and SynchroEdit).
> 
> A few things we have noticed off-hand:
> 
> - - Safari 3 seems to consistently fire "DOMNodeRemoved" events twice for
> the same node removal.
> 
> - - it seems to occasionally have trouble firing "DOMAttrModified" events.
> In the first action of the first test, there is no "ELA SafariWin_2
> class 9 SafariWin" matching the Firefox output.
> 
> - - it seems to insert divs when the user hits enter for newline. I'm not
> sure if this is a special case or if this is the regular behavior.
> 
> - - it unnecessarily (we believe) sets style in by-browser-created
> elements to rgb(r#,g#,b#); instead of using the previously defined class
> attribute. While this may be a safe bet around css declarations which
> only apply to specific element types, the very fact they apply to
> specific element types should prevent the coloring from being forcibly
> inherited. Perhaps use class always, and if the class is
> element-specific, the css generator wanted the color for those elements
> only, and if they want it differently, they'll change the css?
> 
> - - the DOM event output for boldifying text seems broken.
> 
> - - in our test #3 (move to end of bolded "hello" and hit enter), the
> output seems broken as well.
> 
> - - text-justifications (the "justify{left|right|center|full}" commands)
> do not fire any DOM mutation events (should fire style change to e.g.
> "text-align: center"). In fact, it seems DOM mutation events as a whole
> are prevented from firing when justifying.
> 
> Input on the above greatly appreciated!
> 
> - -Kalle.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFGihzndNQyXs/kj34RAv0fAKDTLILR+3eipNpwYct0tEgK38QWPwCdFXaQ
> ijgOc0GmBhzyF/0YxRslaAw=
> =0jpE
> -----END PGP SIGNATURE-----






More information about the webkit-dev mailing list