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 <[EMAIL PROTECTED]> 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----- _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev