NEW 98146
[GTK] accessibility/svg-bounds.html requires platform-specific baseline 
https://bugs.webkit.org/show_bug.cgi?id=98146
Summary [GTK] accessibility/svg-bounds.html requires platform-specific baseline
Zan Dobersek
Reported 2012-10-02 04:39:44 PDT
TSIA.
Attachments
GTK output (700 bytes, text/plain)
2012-10-02 08:10 PDT, Zan Dobersek 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Zan Dobersek
Comment 1 2012-10-02 08:10:30 PDT
Created attachment 166688 [details] GTK output This is the output GTK builders are producing.
Zan Dobersek
Comment 2 2012-10-02 08:12:33 PDT
(In reply to comment #1) > Created an attachment (id=166688) [details] > GTK output > > This is the output GTK builders are producing. This is substantially different that Mac's output: http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/accessibility/svg-bounds-expected.txt Joanie, Mario, thoughts?
Joanmarie Diggs
Comment 3 2012-12-09 16:38:58 PST
(In reply to comment #2) http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/accessibility/svg-bounds-expected.txt > > Joanie, Mario, thoughts? ATK doesn't keep track of (or provide access to) the location of the mouse pointer or the "click point." Any test which requires that will necessarily fail. Because our DRT needs to return *something* regardless, we return 0.0 and this test is using that value in calculations. Hence the wacky results. You think we should try to find some other (e.g. Gdk) means to try to determine where the mouse pointer is and/or has clicked, or should this test just be moved to the mac platform?
Joanmarie Diggs
Comment 4 2012-12-10 01:53:19 PST
Update: Chris mentioned that what the mac does is take the center of the bounding box. This we can do in Atk. (Sorry for the noise!)
Note You need to log in before you can comment on or make changes to this bug.