Re: IndexedDB: undefined parameters
On Oct 11, 2012 5:51 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/11/12 8:43 PM, Jonas Sicking wrote: Even for an API like: void bar(optional int x); void bar(MyInterface? x); with or without the treat undefined as not-passed rule, it's definitely not obvious which one bar(undefined); would call. I think the WebIDL spec unambiguously makes it match the second one, but I wouldn't call that obvious to authors. It's the second one as written. If the int arg there were [TreatUndefinedAs=Missing], then the first overload would be chosen, as WebIDL is written today. And if we made undefined default to missing, it would presumably be the first one in this example. I think that whatever we choose to do here, patterns like the ones in your or my example aren't going to be obvious to web authors. Which is why I think we should discourage them in prose or in rules in WebIDL. In general, WebIDL is ultimately a spec aimed at spec authors, not at developers. We have to make spec authors assume some level of responsibility for the APIs that they create. I'm not that sanguine about it so far, but maybe that's because most spec authors so far don't really understand WebIDL very well... I somewhat agree, but I don't think that anything we do here is going to have a big effect on what spec authors do. If so, all we're really saying is that overload resolution will drop _trailing_ undefined from the argc before determining the overload to use, right? If we go with option B above, then doing that sounds good yes. I can live with that. For what it's worth, I'm fine with either function getting selected from your original example. / Jonas
[Bug 15994] origin attribute
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15994 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution|--- |DUPLICATE --- Comment #4 from Ian 'Hixie' Hickson i...@hixie.ch --- *** This bug has been marked as a duplicate of bug 17823 *** -- You are receiving this mail because: You are on the CC list for the bug.
full screen api
There’s a recent post on a phishing attack using the full screen api [1][2}[3]. Running the example attack, Firefox and Chrome both put up a popup at the top saying the site has gone full screen and asking to approve or deny. But for both of them the screen is already full screen and active (Firefox greys the content but doesn’t disable it). So if the user doesn’t see the popup or ignores it, they can think they’re interacting with another site. In the example, it is a bank. Why not require in the spec that it doesn’t go full screen until after the user approves? That would at least force the user to pay attention to the popup. A note in the warning to users that full screen apps can mimic other sites may be useful. The draft now says “User agents should ensure, e.g. by means of an overlay, that the end user is aware something is displayed fullscreen.”. That “should” should be “MUST” and it should say no switch can happen to full screen until after the user has approved. The draft also says “This specification was published by the WHATCGhttp://www.w3.org/community/whatwg/. It is not a W3C Standard nor is it on the W3C Standards Track” which is a bit confusing for a draft I got off the WebApps WG page, is a deliverable in the WebApps charter and which has been published as a FPWD by the WG. [1] http://feross.org/html5-fullscreen-api-attack/ [2] http://threatpost.com/en_us/blogs/proof-concept-exploits-html5-fullscreen-api-social-engineering-100912 [3] http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Re: full screen api
There was a limited discussion on that a few days ago with the limited consensus (?) being that requiring user-consent up front before switching to fullscreen is desired, should be in the standard and isn't sacrificing UX. On Fri, Oct 12, 2012 at 8:20 PM, Carr, Wayne wayne.c...@intel.com wrote: There’s a recent post on a phishing attack using the full screen api [1][2}[3]. Running the example attack, Firefox and Chrome both put up a popup at the top saying the site has gone full screen and asking to approve or deny. But for both of them the screen is already full screen and active (Firefox greys the content but doesn’t disable it). So if the user doesn’t see the popup or ignores it, they can think they’re interacting with another site. In the example, it is a bank. Why not require in the spec that it doesn’t go full screen until after the user approves? That would at least force the user to pay attention to the popup. A note in the warning to users that full screen apps can mimic other sites may be useful. The draft now says “User agents should ensure, e.g. by means of an overlay, that the end user is aware something is displayed fullscreen.”. That “should” should be “MUST” and it should say no switch can happen to full screen until after the user has approved. The draft also says “This specification was published by the *WHATCG*http://www.w3.org/community/whatwg/. It is not a W3C Standard nor is it on the W3C Standards Track” which is a bit confusing for a draft I got off the WebApps WG page, is a deliverable in the WebApps charter and which has been published as a FPWD by the WG. [1] *http://feross.org/html5-fullscreen-api-attack/*http://feross.org/html5-fullscreen-api-attack/ [2] * http://threatpost.com/en_us/blogs/proof-concept-exploits-html5-fullscreen-api-social-engineering-100912 *http://threatpost.com/en_us/blogs/proof-concept-exploits-html5-fullscreen-api-social-engineering-100912 [3] *http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html*http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
