WebKit does not handle fallback custom cursors I should have caught the fallback cursor issue when reviewing darin's orginal patch: http://bugzilla.opendarwin.org/show_bug.cgi?id=5689
From the spec: http://www.w3.org/TR/REC-CSS2/ui.html#cursor-props "If the user agent cannot handle the first cursor of a list of cursors, it should attempt to handle the second, etc. If the user agent cannot handle any user-defined cursor, it must use the generic cursor at the end of the list."
http://www.w3.org/Graphics/SVG/Test/20030813/svggen/interact-cursor-01-f.svg Demonstrates cursor fallback behavior. http://www.w3.org/TR/css3-ui/ also has some example code.
Even though I did the original custom cursor work, I suggest that someone else do the "list of cursors" and fallback machinery work.
Unless I'm missing something, this means that WebKit cannot handle any custom cursor specified in accordance with the spec, and also any custom cursor that WebKit handles is specified incorrectly.
I spoke with hyatt and darin this evening. We've come up with a pretty simple fix for this. 1. We will need a new class, perhaps called CursorDescription. (like FontDescription). This will contain CurorType enum (just like RenderStyle::cursor() does today), as well as a CachedImage* (just like cursorImage() does today), as well as a CursorDescription next pointer (CursorDescription* m_next; CursorDescription* next() const;) 2. RenderStyle::cursor() will stay (to optimize for the common single-specified cursor case). RenderStyle::cursorImage() will change to CursorDescription* RenderStyle::cursorList(). 3. Either cursor() will return a special CURSOR_LIST enum value, or simply cursorList() returning non-null will trigger the cursor list fallback behavior instead of the normal single-cursor case. That's pretty much it. This should be a pretty small patch and shouldn't take more than a couple hours to code up.
There's a lot work already done in an unfinished patch for bug 6002.
One other thing I forgot. The CursorDescription class can't just point to a CacheImage, as the cursor might not just be an image. It will need to point to either an SVGCursorElement (bug 6002) or a CachedImage, FloatPoint (hotspot -- as part of CSS3) pair. Perhaps we'll want an abstract class to codify this CursorProvider interface. Not sure.
Fixed as part of bug 6002