Re: [webkit-dev] Documentation for WTF/JSC exports?
On Thu, Mar 22, 2012 at 10:38 AM, Eric Seidel e...@webkit.org wrote: Thank you. Mark Rowe was kind enough to resolve https://bugs.webkit.org/show_bug.cgi?id=81838#c8 in http://trac.webkit.org/changeset/111634. I've found that some of the Weak External Symbol errors from http://pastebin.com/dVjV8UiR can be resolved by marking the functions in question as inline, but that doesn't seem like the right fix. Some others like: ERROR: symbol double WTF::strtod(WTF::AllowTrailingJunkTag)0, (WTF::AllowTrailingSpacesTag)0(char const*, char**) You may need GCC_SYMBOLS_PRIVATE_EXTERN = YES; on WTF.xcconfig. JavaScriptCore.xcconfig has it. Are for functions which are not even in headers: http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/dtoa.cpp#L651 So it's unclear what's causing those. Thank you for your attempts at documentation. Perhaps that will make clear how these exports are supposed to work. :) -eric On Wed, Mar 21, 2012 at 6:21 PM, Hajime Morrita morr...@google.com wrote: I'll write a draft so that ports' expert can fill missing pieces. -- morrita On Thu, Mar 22, 2012 at 9:49 AM, Eric Seidel e...@webkit.org wrote: Do we have any documentation for how the current symbol export system for WTF/JSC is supposed to work? I'm hitting errors when trying to move WTF files to their own libwtf.a, such as: https://bugs.webkit.org/show_bug.cgi?id=81838 and http://pastebin.com/dVjV8UiR But looking at http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/ExportMacros.h It appears most of those macros are never used! (Like WTF_EXPORT_CLASS, for example.) So when trying to resolve errors such as: https://bugs.webkit.org/show_bug.cgi?id=81838#c8 The path is unclear. Perhaps there is a wiki somewhere on how this system is supposed to work? -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Adding Buildbot for the BlackBerry port
Hi, As many of you may notice, we (as the WebKit team at RIM) are now more active in contributing patches to WebKit.org. To move another step forward, we're in preparation for bringing a build machine to WebKit.org to build our BlackBerry port. I was reading this http://trac.webkit.org/wiki/BuildBot, and now I would like to find a contact so we can discuss more detail offline. Could someone who currently managing the build master please contact me at m...@rim.commailto:m...@rim.com? Thanks in advance! Regards, Ming X. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding Buildbot for the BlackBerry port
Hi Ming, I would be happy to help you out with this. Send me an email and we can coordinate. Lucas On Mar 22, 2012, at 8:15 AM, Ming Xie wrote: Hi, As many of you may notice, we (as the WebKit team at RIM) are now more active in contributing patches to WebKit.org. To move another step forward, we’re in preparation for bringing a build machine to WebKit.org to build our BlackBerry port. I was reading this http://trac.webkit.org/wiki/BuildBot, and now I would like to find a contact so we can discuss more detail offline. Could someone who currently managing the build master please contact me at m...@rim.com? Thanks in advance! Regards, Ming X. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ 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
Re: [webkit-dev] Adding -webkit-image-set CSS function
Hi all, I just wanted to give you an update and let you know that I checked in an initial implementation of this feature yesterday! There was some concern about enabling this everywhere while it's still a work in progress to avoid the problem of any particular port accidentally shipping with a half-baked implementation. So I added an ENABLE flag to Platform.h that is currently only enabled on Mac and iOS. I will be filing follow-up bugs and linking them to the original shortly. -Beth On Mar 5, 2012, at 1:19 PM, Beth Dakin bda...@apple.com wrote: Hi! On Mar 1, 2012, at 5:00 PM, Hajime Morrita morr...@chromium.org wrote: Are you going to add any compilation flags? I am not planning to add compilation flags since this won't affect any existing web content. Also, if there is a Bugzilla entry to track this, I'd like to know that. https://bugs.webkit.org/show_bug.cgi?id=80322 Thanks for your reply! -Beth ___ 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
Re: [webkit-dev] Documentation for WTF/JSC exports?
I think that might have worked. :) Thanks. On Thu, Mar 22, 2012 at 12:36 AM, Hajime Morrita morr...@chromium.org wrote: On Thu, Mar 22, 2012 at 10:38 AM, Eric Seidel e...@webkit.org wrote: Thank you. Mark Rowe was kind enough to resolve https://bugs.webkit.org/show_bug.cgi?id=81838#c8 in http://trac.webkit.org/changeset/111634. I've found that some of the Weak External Symbol errors from http://pastebin.com/dVjV8UiR can be resolved by marking the functions in question as inline, but that doesn't seem like the right fix. Some others like: ERROR: symbol double WTF::strtod(WTF::AllowTrailingJunkTag)0, (WTF::AllowTrailingSpacesTag)0(char const*, char**) You may need GCC_SYMBOLS_PRIVATE_EXTERN = YES; on WTF.xcconfig. JavaScriptCore.xcconfig has it. Are for functions which are not even in headers: http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/dtoa.cpp#L651 So it's unclear what's causing those. Thank you for your attempts at documentation. Perhaps that will make clear how these exports are supposed to work. :) -eric On Wed, Mar 21, 2012 at 6:21 PM, Hajime Morrita morr...@google.com wrote: I'll write a draft so that ports' expert can fill missing pieces. -- morrita On Thu, Mar 22, 2012 at 9:49 AM, Eric Seidel e...@webkit.org wrote: Do we have any documentation for how the current symbol export system for WTF/JSC is supposed to work? I'm hitting errors when trying to move WTF files to their own libwtf.a, such as: https://bugs.webkit.org/show_bug.cgi?id=81838 and http://pastebin.com/dVjV8UiR But looking at http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/ExportMacros.h It appears most of those macros are never used! (Like WTF_EXPORT_CLASS, for example.) So when trying to resolve errors such as: https://bugs.webkit.org/show_bug.cgi?id=81838#c8 The path is unclear. Perhaps there is a wiki somewhere on how this system is supposed to work? -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore
Going ahead with the land now. Will be around for several hours fixing builds. I'm sorry for any breaks. -eric On Wed, Mar 21, 2012 at 7:08 PM, Eric Seidel e...@webkit.org wrote: I've posted my first-draft patch to: https://bugs.webkit.org/show_bug.cgi?id=81844 If port maintainers would like to apply it locally and upload improved versions (or upload diffs on top of that version) that would be most welcome. svn-apply seems to be having trouble with the adds for the WTF files, thus causing all the EWS bots to fail. I'm also working on getting a git branch (on github) of my changes, to make it easier for port maintainers to send me updates (instead of passing around 5MB diffs). At this point it may be best to just land the change tomorrow and fix all the buildbots after the fact. We should be very close, with all the header work which has been done over the last month. -eric On Tue, Mar 20, 2012 at 5:18 PM, Eric Seidel e...@webkit.org wrote: We're ready to complete the move. https://bugs.webkit.org/show_bug.cgi?id=80911 should land later this evening, moving JavaScriptCore/wtf/Platform.h to Source/WTF/Platform.h Tomorrow (Weds) I will move a .cpp file in the same way. Thursday, I will move all the rest of the WTF files. I will also update svn-apply so that in-flight patches should transparently patch the right files post-move. Let me know if you have questions or concerns. -eric On Tue, Feb 28, 2012 at 3:53 PM, Eric Seidel e...@webkit.org wrote: I'm going to push off the move, probably until next week. Thank you for the Qt patch! I'll post a patch for Mark and we can discuss further from there. -eric On Tue, Feb 28, 2012 at 7:38 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, I uploaded the necessary buildfix for Qt to the bugzilla: https://bugs.webkit.org/show_bug.cgi?id=79783 . Please be careful with moving JavaScriptCore/wtf to WTF, because we need zillion trivial fixes for case sensitive file systems. (~4000 files!!!) I made it locally to be able prepare the Qt buildfix and I had to replace all wtf to WTF includes everywhere. (*.cpp, *.h, *.y, *.py, *.pl, *.pm, ...) The patch is huge, ~2Mb and ~4000 files are affected. I suggest landing the following patches separately: - Moving Sources/JavaScriptCore/wtf -- Sources/WTF - s/wtf/WTF/g patch :) - platform buildfixes Please let me know if you have the new date for landing these patches. I would be happier with a more CET timezone friendly timing. - 08:00-00:00 in CET. br, Ossy Eric Seidel írta: We've been talking about moving WTF out of JavaScriptCore for a long time. We believe we're nearly there. https://bugs.webkit.org/show_bug.cgi?id=75673 This will mean that WTF will be built as a separate static library on all ports. The plan is to do this move all in one piece, after work hours PST, when the tree is least active. It won't be the most beautiful transition (as we're likely to break at least one port in the process), but we'll try not to make too much of a mess. We believe all the ports are ready for the move, except AppleWin: https://bugs.webkit.org/show_bug.cgi?id=75897 Once AppleWin is ready we'll schedule a date for the transition and announce it one this thread. Thanks! -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses
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: 1. 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.) 2. 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
Re: [webkit-dev] Moving WTF out of JavaScriptCore
The move appears to be a success. Mac, CrMac, CrWin, CrLinux, Gtk and Qt are all back building again. Win, CrAndroid and EFL are in progress. HUGE thank you to Mark Rowe, Tony Chang, Jessie Berlin, Martin Robinson, Csaba Osztrogonac, Carlos Garcia Campos, Michael Saboff, and Filip Pizlo for all their help with their respective platforms! If I can be of further help, let me know. -eric On Thu, Mar 22, 2012 at 3:50 PM, Eric Seidel e...@webkit.org wrote: Going ahead with the land now. Will be around for several hours fixing builds. I'm sorry for any breaks. -eric On Wed, Mar 21, 2012 at 7:08 PM, Eric Seidel e...@webkit.org wrote: I've posted my first-draft patch to: https://bugs.webkit.org/show_bug.cgi?id=81844 If port maintainers would like to apply it locally and upload improved versions (or upload diffs on top of that version) that would be most welcome. svn-apply seems to be having trouble with the adds for the WTF files, thus causing all the EWS bots to fail. I'm also working on getting a git branch (on github) of my changes, to make it easier for port maintainers to send me updates (instead of passing around 5MB diffs). At this point it may be best to just land the change tomorrow and fix all the buildbots after the fact. We should be very close, with all the header work which has been done over the last month. -eric On Tue, Mar 20, 2012 at 5:18 PM, Eric Seidel e...@webkit.org wrote: We're ready to complete the move. https://bugs.webkit.org/show_bug.cgi?id=80911 should land later this evening, moving JavaScriptCore/wtf/Platform.h to Source/WTF/Platform.h Tomorrow (Weds) I will move a .cpp file in the same way. Thursday, I will move all the rest of the WTF files. I will also update svn-apply so that in-flight patches should transparently patch the right files post-move. Let me know if you have questions or concerns. -eric On Tue, Feb 28, 2012 at 3:53 PM, Eric Seidel e...@webkit.org wrote: I'm going to push off the move, probably until next week. Thank you for the Qt patch! I'll post a patch for Mark and we can discuss further from there. -eric On Tue, Feb 28, 2012 at 7:38 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, I uploaded the necessary buildfix for Qt to the bugzilla: https://bugs.webkit.org/show_bug.cgi?id=79783 . Please be careful with moving JavaScriptCore/wtf to WTF, because we need zillion trivial fixes for case sensitive file systems. (~4000 files!!!) I made it locally to be able prepare the Qt buildfix and I had to replace all wtf to WTF includes everywhere. (*.cpp, *.h, *.y, *.py, *.pl, *.pm, ...) The patch is huge, ~2Mb and ~4000 files are affected. I suggest landing the following patches separately: - Moving Sources/JavaScriptCore/wtf -- Sources/WTF - s/wtf/WTF/g patch :) - platform buildfixes Please let me know if you have the new date for landing these patches. I would be happier with a more CET timezone friendly timing. - 08:00-00:00 in CET. br, Ossy Eric Seidel írta: We've been talking about moving WTF out of JavaScriptCore for a long time. We believe we're nearly there. https://bugs.webkit.org/show_bug.cgi?id=75673 This will mean that WTF will be built as a separate static library on all ports. The plan is to do this move all in one piece, after work hours PST, when the tree is least active. It won't be the most beautiful transition (as we're likely to break at least one port in the process), but we'll try not to make too much of a mess. We believe all the ports are ready for the move, except AppleWin: https://bugs.webkit.org/show_bug.cgi?id=75897 Once AppleWin is ready we'll schedule a date for the transition and announce it one this thread. Thanks! -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] CSS3 Selectors3 test suite
I've recently been greening Chromium's expectations for css3/selectors3. ~10% of these test need interaction (e.g. hovering over a link or selecting text). Given that this is an imported test suite does it make sense to add the appropriate layoutTestController hooks? As it is, the tests aren't really verifying correctness. Also, this test suite is a great example of one that I think it would make more sense for us to check in reftest expected results instead of png+rendertreedump. These tests are explicitly testing selector matching only, so it would be easy to write reftests that have a high confidence of accurately verifying correctness. They'd only fail if we had some egregious bug such that we painted everything green as white. Presumably we'd notice such a bug through other means. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CSS3 Selectors3 test suite
On Thu, Mar 22, 2012 at 18:41, Ojan Vafai o...@chromium.org wrote: I've recently been greening Chromium's expectations for css3/selectors3. ~10% of these test need interaction (e.g. hovering over a link or selecting text). Given that this is an imported test suite does it make sense to add the appropriate layoutTestController hooks? As it is, the tests aren't really verifying correctness. Seems like a good idea. Also, this test suite is a great example of one that I think it would make more sense for us to check in reftest expected results instead of png+rendertreedump. These tests are explicitly testing selector matching only, so it would be easy to write reftests that have a high confidence of accurately verifying correctness. They'd only fail if we had some egregious bug such that we painted everything green as white. Presumably we'd notice such a bug through other means. Again, I think that would be valuable (and lead to way fewer incorrect failures and thus lowering the maintenance costs over time). As such I'd gladly help with the conversion work if we do end up going down that route. -- Emil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CSS3 Selectors3 test suite
On Thu, Mar 22, 2012 at 6:41 PM, Ojan Vafai o...@chromium.org wrote: I've recently been greening Chromium's expectations for css3/selectors3. ~10% of these test need interaction (e.g. hovering over a link or selecting text). Given that this is an imported test suite does it make sense to add the appropriate layoutTestController hooks? As it is, the tests aren't really verifying correctness. That sounds great but can we make this change upstream on http://hg.csswg.org/test/file/8ca008901be5/approved/selectors3 ? It seems like other vendors would benefit form this change as well. Also, this test suite is a great example of one that I think it would make more sense for us to check in reftest expected results instead of png+rendertreedump. These tests are explicitly testing selector matching only, so it would be easy to write reftests that have a high confidence of accurately verifying correctness. Again, can we do that upstream? It seems like adding reference files for those tests will be valuable for other browser vendors as well, and people working on these test suites really want feedbacks from browser vendors. I assume Gecko needs reference files as well when they import this test suite so it'll at least benefit Mozilla. And it'll be really silly if each browser vendor invented their own reference files. Doing it upstream also have a benefit of making the effort visible to test authors, who might be able to give us valuable feedbacks. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses
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
Re: [webkit-dev] CSS3 Selectors3 test suite
On Mar 22, 2012, at 6:41 PM, Ojan Vafai o...@chromium.org wrote: I've recently been greening Chromium's expectations for css3/selectors3. ~10% of these test need interaction (e.g. hovering over a link or selecting text). Given that this is an imported test suite does it make sense to add the appropriate layoutTestController hooks? As it is, the tests aren't really verifying correctness. I don't think it is a good idea to change imported suites unless we can do it a non-destructive way (e.g. all tests in this directory get this script added to them). If we want to split up the tests that require interaction from the others, we should do that upstream and see if we can make as many as we can not require explicit interaction. Also, this test suite is a great example of one that I think it would make more sense for us to check in reftest expected results instead of png+rendertreedump. These tests are explicitly testing selector matching only, so it would be easy to write reftests that have a high confidence of accurately verifying correctness. They'd only fail if we had some egregious bug such that we painted everything green as white. Presumably we'd notice such a bug through other means. Again, I think this should happen upstream in the CSS working group. -Sam Ojan ___ 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
Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses
Suppose I am using a framework does window.frameElement for various
reasons. When that framework is used in an iframe, it causes errors to
appear in the console.
For example, suppose the framework does this:
var a;
try {
a = window.frameElement; // WebKit outputs a console error here.
if (!a)
return;
} catch (e) {
return;
}
...
Now if I had this new method, I would change the framework to do this:
var a;
try {
// WebKit doesn't throw an exception for x-origin parent access, but it
will puts errors in the console.
// Do an explicit access check to avoid having the error appear in the
console.
var canAccessParent = window.parent.webkitCanAccess;
if (canAccessParent != undefined !canAccessParent)
return;
a = window.frameElement;
if (!a)
return;
} catch (e) {
return;
}
...
Does that help? (The use case is about avoiding spurious console error
messages, so console error messages are real errors.)
dave
On Thu, Mar 22, 2012 at 8:44 PM, Sam Weinig wei...@apple.com wrote:
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:
1. 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.)
2. 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
Re: [webkit-dev] UPDATED Re: Version control survey
On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak m...@apple.com wrote: I made a bad choice of survey site. They want to charge me to see more than 100 responses or to export the data, but they won't take my money. Sadness. Please try this survey instead, it will run through the 17th. The survey seems to be over. Any word on the results? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses
I wonder if we could expose the parent document's origin, so you could
write the check as follows:
if (parent.location.origin != location.origin)
return;
It's slightly subtle because we wouldn't want to expose the origin of
child frames (then you could probe the redirect structure of private
networks), but exposing ancestor origins seems tenable.
Adam
On Thu, Mar 22, 2012 at 9:16 PM, David Levin le...@chromium.org wrote:
Suppose I am using a framework does window.frameElement for various
reasons. When that framework is used in an iframe, it causes errors to
appear in the console.
For example, suppose the framework does this:
var a;
try {
a = window.frameElement; // WebKit outputs a console error here.
if (!a)
return;
} catch (e) {
return;
}
...
Now if I had this new method, I would change the framework to do this:
var a;
try {
// WebKit doesn't throw an exception for x-origin parent access, but it
will puts errors in the console.
// Do an explicit access check to avoid having the error appear in the
console.
var canAccessParent = window.parent.webkitCanAccess;
if (canAccessParent != undefined !canAccessParent)
return;
a = window.frameElement;
if (!a)
return;
} catch (e) {
return;
}
...
Does that help? (The use case is about avoiding spurious console error
messages, so console error messages are real errors.)
dave
On Thu, Mar 22, 2012 at 8:44 PM, Sam Weinig wei...@apple.com wrote:
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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
