Hey Dave, Can you describe the use case for this new property? When would an author use it?
-Sam On Mar 22, 2012, at 4:16 PM, David Levin <le...@chromium.org> wrote: > Resurrecting a really old thread so continue the conversation now that I'm > hitting this issue :). > > On Mon, Aug 16, 2010 at 2:16 PM, Sam Weinig <sam.wei...@gmail.com> wrote: > I am not sure I agree. Does our behavior actually cause any real bugs in the > places you have tracked down? The log spam really doesn't seem like an > issue, we can remove it if we want to, but have found it useful in the past. > > Speaking as someone who working on a web app, the log spam is a significant > issue because: > It clutters up the console output making it harder to find the real error. > (It is hard to explain how much worse this makes the experience until you > have to deal with a sophisticated web page. Image looking at the logs from > your app and seeing lots of error messages -- many of which are this one and > then a real one hidden among them -- from personal experience.) > When more sophisticated end users see it, they think there is a problem in > the app and report it (and it could be that they include this in their error > report and ignore other more important things). > I understand that that the console/log spam is useful to detect real issues > as well (given that WebKit doesn't throw an exception in this case). > > Would people find it acceptable to have window.webkitCanAccess so that a web > page can use that property first to detect the cross origin issue and avoid > doing an access which would trigger the console spam? (I would also be fine > with an exception instead of log spam.) > > Thanks, > dave > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
