Re: [webkit-dev] Can we remove Notification.show()?
On Mon, Jan 28, 2013 at 5:41 PM, Jochen Eisinger joc...@chromium.org wrote: A side-effect of that decision is that permission is a static attribute, which we can't currently implement in V8 :-/ Not entirely true. We cannot use FunctionTemplate to do this but we can add the V8 accessor in V8PerContextData::constructorForTypeSlowCase. -- erik ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Changes to DOM related exceptions
The specs for DOM related exceptions has changed a bit over the last few years. These changes have been made to simplify things, both for end users and implementers. Fortunately for the spec writers no two browsers agreed on the behavior, so end users could not depend on the details of the old specs. Unfortunately for us, we implemented things according to the old spec. So what changed? A lot of the new specs just throw DOMExceptions (instead of more specialized exceptions like RangeException). Also, new error types have a code property of 0. What might break? Code that does instanceof checks or accesses removed exception constructors. This should be a low risk since, like previously mentioned this never worked cross browser. For Apple dashboard widgets, this should still be a safe change since checking the type of an exception is hardly ever done (we don't even have tests covering this). -- erik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changes to DOM related exceptions
To clarify. I intend to make changes to WebKit to align our code with the latest specs where possible. On Wed, Dec 5, 2012 at 3:29 PM, Erik Arvidsson a...@chromium.org wrote: The specs for DOM related exceptions has changed a bit over the last few years. These changes have been made to simplify things, both for end users and implementers. Fortunately for the spec writers no two browsers agreed on the behavior, so end users could not depend on the details of the old specs. Unfortunately for us, we implemented things according to the old spec. So what changed? A lot of the new specs just throw DOMExceptions (instead of more specialized exceptions like RangeException). Also, new error types have a code property of 0. What might break? Code that does instanceof checks or accesses removed exception constructors. This should be a low risk since, like previously mentioned this never worked cross browser. For Apple dashboard widgets, this should still be a safe change since checking the type of an exception is hardly ever done (we don't even have tests covering this). -- erik -- erik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] What is the relationship between WebIDL and WebKitIDL?
On Wed, Mar 14, 2012 at 07:08, Seo Sanghyeon sanx...@gmail.com wrote: However, there doesn't seem to be any progress on this. I am interested in moving this forward. Is it okay? Yes. It would be much appreciated. -- erik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CSS properties vs. their JS bindings on the style object
How about making this a compile time flag or runtime flag so that Apple Dashboard and iOS can keep it but let other users of WebKit disable it? erik On Tue, Feb 28, 2012 at 22:23, Benjamin Poulain benja...@webkit.org wrote: On Tue, Feb 28, 2012 at 9:48 PM, t...@codeaurora.org wrote: Seriously, I'm not sure how to proceed on this. It does seem to be outside the spec. Either update the spec or create a path to deprecate the bug. Personally, this feature sounds like it could be useful for web developers so updating the spec might not be a bad idea. Benjamin ___ 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] focusin/focusout events
I think the order as specced at
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-focusevent-event-order
is fine. It seems to solve the ordering from a backwards compatibility
case.
The spec leaves out when document.activeElement is changed though.
erik
On Mon, Jul 26, 2010 at 18:32, Ojan Vafai o...@chromium.org wrote:
There are a few concerns on the table:
1. We don't match the DOM3 spec. I'm not too worried about this. Neither
does anyone else. We could probably get the spec to change if noone is going
to implement it as is.
2. We don't match other browsers. It's not clear to me what changes are
worth making here.
3. There's no way to get the selection *before* an element is blurred.
The third one is the only one I really care about solving, in the short term
anyways. I'd like there to be a blur-like event that we fire *before*
clearing the selection. With our current ordering of events, that would mean
clearing the selection after the blur event or the focusout event or both,
which no browser does. That said, it might be safe to just change this.
Since no browser has a selection during the blur event and only IE has one
during focusout, we might be able to get away with just changing that as
noone should be depending on the selection at that point. Perhaps that's
worth trying?
On Mon, Jul 26, 2010 at 12:06 AM, Darin Adler da...@apple.com wrote:
You mention activeElementId, but there must be other side effects that
matter.
The only other side effects I can think of are the focus outline (which
could probably be tested via getComputedStyle?) and clearing the selection.
In non-IE the selection isn't cleared if focus is moving across frames. But
when focus moves within the same document, you get the following:
IE 8: The selection is cleared after the focusout event and before focusin,
blur, focus.
WebKit Opera: It's cleared before any events are fired.
FF 3.6: It's cleared before any events are fired unless focus is moving to a
textarea/input (not contentEditable!).
It's a bit gross, but the only solution I can think of is to fire the
following events in WebKit (in this order):
focusout
focusin
{remove focus and clear selection as appropriate}
blur
domfocusout
{add focus to new node and set selection as appropriate}
focus
domfocusin
This sequence doesn’t sound too terrible to me. But I don’t fully
understand the proposal. At the time the focusin event fires we won’t yet
know what item is getting focus?
I think we do know this and it wouldn't be too hard to implement. It's just
a question of what we think the best behavior is. Specifically,
in Document::setFocusedNode, we know both the new focused node and the old
focused node when firing these events.
Is the design that the focusin event’s target knows it will be getting
focused? What about focus changes that come about along with selection
changes? Or is there no such thing?
Sounds like some differences are:
1) The blur event in Opera and IE will see the new focused node as the
active element, but in WebKit and Firefox will see no active element at all.
2) Same for DOMFocusOut, but IE and Firefox are not affected.
3) IE fires focusout before the selection is cleared if the element being
focused is the body (e.g. click from a contentEditable onto a non-focusable
element).
Is there a good reason to do blur the Firefox way instead of the Opera/IE
way? Maybe because it’s the legacy WebKit way, and hence likely to be
depended on by WebKit-tested or WebKit/Firefox-tested content?
My only concern was backwards compatibility, but I have no evidence that it
is or isn't a valid concern.
Ojan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Keypress event for ctrl+key and/or ⌘+key?
On Mon, Oct 19, 2009 at 18:03, Oliver Hunt oli...@apple.com wrote: On Oct 19, 2009, at 5:18 PM, Erik Arvidsson wrote: I'm trying to clean up some inconsistencies with when keypress events are dispatched. WebKit's key event model is modeled to be compatible with Internet Explorer and Internet Explorer does not fire keypress for Ctrl+key [1] The key event model was designed to be as compatible as possible with both IE and firefox, so it would be helpful to know the firefox behaviour. Firefox fires keypress events for everything. Safari Win does not fire any keypress events when ctrl is held down Safari Mac fires keypress events when command is held down Safari Mac fires keypress events when ctrl is held down Chromium Win fires keypress events for some keys when ctrl is held down Chromium Linux fires keypress events for some keys when ctrl is held down (matches chromium windows) Chromium Mac does not fire keypress events when command is held down Chromium Mac does not fire keypress events when ctrl is held down There are two possible solutions to this problem. 1. Always fire keypress events no matter what modifiers are held down 2. Do not fire keypress events unless content would be generated Expected behaviour is for key events to be sent regardless of ctrl/command pressed. The real issue is whether application shortcuts get precedence over DOM event handlers, currently on mac the DOM event handlers get precedence (and thus the ability to override/prevent application shortcuts) and on windows they don't. This is entirely a byproduct of implementation and the difference really isn't something we want. --Oliver I think we should try to enable firing keypress events on Windows again and see if it leads to any troubles. -- erik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit revision number to build number tool
I wrote a simple tool that allows me to quickly look up the WebKit build number based on an SVN revision number. http://webkit-util.appspot.com/rev/ http://webkit-util.appspot.com/rev/45980 I wrote this mainly so I could figure out what WebKit build number to check for in our JS library when a WebKit bug was fixed. I hope other people might find this useful. Future enhancements: * Take a bug number as an input instead of a revision number * Output the Safari version that has this revision in it * Output the Chrome version that has this revision in it -- erik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit revision number to build number tool
On Sun, Oct 18, 2009 at 16:22, Darin Adler da...@apple.com wrote: On Oct 18, 2009, at 4:14 PM, Erik Arvidsson wrote: I wrote a simple tool that allows me to quickly look up the WebKit build number based on an SVN revision number. http://webkit-util.appspot.com/rev/ http://webkit-util.appspot.com/rev/45980 I wrote this mainly so I could figure out what WebKit build number to check for in our JS library when a WebKit bug was fixed. I suspect this won’t work reliably for that purpose, because the WebKit build number you need is often the one it’s bumped to *after* the bug fix. At the time the bug is fixed, it’s possible, even likely, that the build number is still an older one. It does exactly that. If you enter revision A it will check for a Version.xcconfig version that is larger than A. For example if you enter 48930 it will check the changelog and find 48936 which gives the build number 532.2. -- erik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit revision number to build number tool
On Sun, Oct 18, 2009 at 16:38, Mark Rowe mr...@apple.com wrote: It looks like it could be useful, but it has a number of problems that would make me wary of relying too heavily on it. For starters, the WebCore version is not exposed to web content at all so it does not make sense to use WebCore's version number for this. The WebKit version would be a more appropriate number to use. How is the WebKit version determined? I was told that the WebCore version was the same. It also presents misleading results. It can report changes as being available much later than they actually were, such as in the case of r45979 which it reports as being fixed in 532.1 when in reality this fix first shipped as part of Safari 4.0.3 in WebKit x531.6. This could pose problems if the results of the tool are used for workarounds in situations where the fix causes the workaround to not function as expected. You are correct. This tool only keeps track of when the build number changes due to changes in Version.xcconfighttp://trac.webkit.org/log/trunk/WebCore/Configurations/Version.xcconfig. I should add a comment about that in the description. A worse case is when the tool reports issues as being fixed *earlier* than they actually were, as is the case with r45712. The tool reports this as being fixed in 531.5 when in reality that version *does not* contain that fix. How does that happen? 531.5 was set at r45738 It presumably also doesn't consider the case where changes are later rolled out. Also wroth pointing out. Thanks for the comments Mark. If you think this tool does more harm than good I'll take it offline. Hopefully it can be fixed since the question which WebKit build to check for is something that a lot of js developers are asking us about. -- erik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
I assume you mean window.navigator?
I think this is a good idea. You should bring this up the WHATWG as well.
2009/7/22 Jungshik Shin (신정식, 申政湜) js...@chromium.org:
Hi,
I proposed exposing the values of the Accept-Langauge list via
window.navigation.acceptLanguages at
https://bugs.webkit.org/show_bug.cgi?id=27555
This email is to get opinions (for and against) on that in case the
bug is not noticed by many. As pointed out by ap in the bug, perhaps,
we have to bring this up in the WHATWG as well. Before I do that, it
may not be a bad idea to know what others her think about it.
Currently, the UI language of a browser is exposed with
window.navigation.language. This can be used by a 'web application' /
widget / browser extension to 'behave differently' per the UI
language.
A lot of web servers also take into account the value of
Accept-Language HTTP header field when determining the UI language of
their web apps or the language of contents to serve when multiple
language versions exist. Moreover, most browsers (Safari, Chrome,
Firefox, IE, and so forth) allow users to add, delete, move up and
down a language to the prioritized list of languages they understand
Some web apps/widgets/browser extensions can also benefit from knowing
the ordered list of languages in Accept-Language.
One particular use case Chrome has in mind is to determine the target
language of translation without a user-intervention. If the source
language is A and the A-L list has {B, C, D}, the target language can
be determined by walking through the list and picking up the first
language for which the translation from A is available. If 'A' is in
the A-L list, perhaps the translation service should not be called. (
See http://crbug.com/14574 )
There might be other cases of 'multi-lingual' applications where the
knowledge of the A-L list can be helpful.
It can be exposed by adding either of the two below to window.navigation
readonly attribute DOMStringList acceptLanguages // a list of
language codes
readonly attribute DOMString acceptLanguages // a comma separated
language codes
Unlike in the Accept-Language http header field, a language in the
list will not have a q-factor associated with it. Instead, they're
sorted in the descending order of the priority.
Any opinion would be welcome.
Jungshik
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
erik
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
