[webkit-dev] DOM Mutation Event compatibility.

[Maciej Stachowiak]

What Dave said about filing bugs is good advice, but some comments  
about the issues you mentioned...

On Jul 3, 2007, at 2:54 AM, Kalle Alm 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.

This definitely sounds like a bug - we could use a reduced test case.

> - - 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.

We might be missing these - this would also explain the lack of  
events you see for some style changes.

> - - 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.

By default we split blocks when the user hits a line break, instead  
of adding <br>

> - - 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?

Does this show up in any of your examples? It's hard for me to read  
the debug output. In general, we don't ever add class values to  
elements that did not have them - we're not trying to guess the  
stylesheet's intent and many style rules set more than just a color.

> - - the DOM event output for boldifying text seems broken.

In what way?

>
> - - in our test #3 (move to end of bolded "hello" and hit enter), the
> output seems broken as well.

In what way?

> - - 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.

It's probably just missing attribute change notifications.

>
> 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev