Re: XHR tests
On Mon, 25 Feb 2008 15:56:25 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: http://tc.labs.opera.com/apis/XMLHttpRequest/responseText/003.htm This is more like a demo than a test case, it doesn't return a pass/fail to the framework and it doesn't really test what TITLE claims. (What it *does* test is that readyState is 1 in the first event sent when you call send() on a synchronous request..). Anne, please fix this test and figure out what you meant to test with this script. This is fixed now. responseText no longer throws and will always return a DOMString. http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/006.htm Tests getAllResponseHeaders() output if the request ends up in an endless redirect loop. Assumes that it should return null. It now tests for the empty string. getAllResponseHeaders() will always return a DOMString. getResponseHeader() will still return null for this case as it already has another case where it returns null. Returning null seems more natural therefore and I don't think it will cause any harm if implementations change that. http://tc.labs.opera.com/apis/XMLHttpRequest/send/003.htm This one passes in Firefox 3 and IE7. Though the alert() statement should probably be removed. Removed. http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/011.htm Same as 010 except it tests for first argument being undefined and IE doesn't actually throw here. Should we change the API so that undefined stringifies as IE does? Does IE stringify for the value too? And what does it do for null? We can fix this when the Web IDL spec is done. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Issue Request for DOM L3 Events
Following up... It was decided to include examples of this type of behavior as a non-normative appendix to the events 3 spec. This allows implementers and developers to be aware of this peculiarity without imposing unnecessary restrictions/limits on the behavior.
DOM3 Events Telcon Minutes, 27 Feb 2008
Hi, WebAPI fans- The minutes for the 27 Feb 2008 DOM3 Events telcon can be found here: http://www.w3.org/2008/02/27-webapi-minutes.html Or as text, below: [1]W3C [1] http://www.w3.org/ - DRAFT - Web API WG Teleconference 27 Feb 2008 [2]Agenda [2] http://www.w3.org/2008/webapps/wiki/27_Feb_2008 See also: [3]IRC log [3] http://www.w3.org/2008/02/27-webapi-irc Attendees Present Carmelo, Andrew_Emmons, Doug, Travis Regrets Chair Doug Scribe Carmelo Contents * [4]Topics 1. [5]DoubleClick 2. [6]Double Click 3. [7]lets differ wheels to next week 4. [8]dblclick Tests 5. [9]'alt'-key 6. [10]mousewheel overview * [11]Summary of Action Items _ trackbot Date: 27 February 2008 scribe Scribe: Carmelo scribe ScribeNick:Carmelo TL Here I am. TL: Changes his name to Travis DS: We decided not to talk about Key events ... We need to decide how to handle keyboards and that sort of things ... Lets start with Double Click DoubleClick Double Click aemmons [12]http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0050.h tml [12] http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0050.html AS: Two issuus Regarding Doubing Click DS: Can u summarize? AS: Should the detail value be for Double Click? ... Consensus is should be teh same as click ... Described and explained teh link above TL: Can an example be provid? R: detail for double click will be the same a the click aemmons RESOLUTION: detail for double click will be the same a the click aemmons RESOLUTION: We accept the current wording in the spec regarding what the current click count means shepazu ACTION: aemmons to add informative examples of different click counts for dblclick [recorded in [13]http://www.w3.org/2008/02/27-webapi-minutes.html#action01] trackbot Created ACTION-246 - Add informative examples of different click counts for dblclick [on Andrew Emmons - due 2008-03-05]. DS: We are finish with double Click lets differ wheels to next week DS: Let's review the DoubleClick Test shepazu [14]http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0161.h tml [14] http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0161.html dblclick Tests shepazu test 1: [15]http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0161.h tml [15] http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0161.html DS; If red shown in the test it means failure DS: Green usually a pass ... Instruction For each test scribe ACTION: Doug to provied test template [recorded in [16]http://www.w3.org/2008/02/27-webapi-minutes.html#action02] trackbot Created ACTION-247 - Provied test template [on Doug Schepers - due 2008-03-05]. DS: Test should work on every Browser ... Test should figure out if person Double Click ... How can we actually check for that? ... We should make a framework for the test scribe ACTION: TL to give us a script library that will add listener events. [recorded in [17]http://www.w3.org/2008/02/27-webapi-minutes.html#action03] trackbot Created ACTION-248 - Give us a script library that will add listener events. [on Travis Leithead - due 2008-03-05]. shepazu ACTION: Travis to provide simple abstraction layer for addEventListener [recorded in [18]http://www.w3.org/2008/02/27-webapi-minutes.html#action04] trackbot Created ACTION-249 - Provide simple abstraction layer for addEventListener [on Travis Leithead - due 2008-03-05]. DS: We will build a script layer for testing Carmelo: How critical is add eventListener? DS: not sure? TL: addEventListener is one of the key pieces different from implementations ... Another piece that is different Scope of the event object itself TL; Will be happy to provide a small library to buil on TL: Will be happy to provide a small library to buil on aemmons [19]http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0164.h tml [19] http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0164.html AE: Above link is an SVG version of the NIST test AS: Lets Move on DS: Ok 'alt'-key shepazu [20]http://www.w3.org/2005/06/tracker/webapi/issues/122 [20] http://www.w3.org/2005/06/tracker/webapi/issues/122 TL: ALT key events is sometimes loose. ... Explained the issue and the scenarios for ALT handling DL: propoesed two options sub/DL/TL/ sub /DL/TL/ DS: Thsi behavious is somehow address in DOM 3 events ... maybe this should be on next week's agenda DS; None of this should be dependent on any OS DS: We cna
Re: Issue Request for DOM L3 Events
I think it's probably worth pointing out that the special handling of ALT is specific to Windows as ALT is used to activate menus, this does not effect MacOS, and may or may not effect the various linux browsers (i honestly have no idea what they do and don't have a linux system to test on). That said my (brief) testing of Safari for Windows shows that Safari correctly pair ALT up/down in all of the scenarios below. The testcase I used is at http://nerget.com/tests/input-testcase.html --Oliver On Feb 21, 2008, at 1:09 PM, Travis Leithead wrote: I’d like to propose a discussion about the handling of the ALT + key combination that will hopefully end in a normative requirement. In observing IE as well as other browsers, there is “good” x-browser consistency between the handling of ALT and pressing a modifier key. While the browsers are mostly consistent, they do so in a way that is not very reliable for web developers because key down/key up pairs are often not respected (key events get dropped in some scenarios). I’ve identified the following scenarios that we can discuss: Scenarios for ALT handling where the key combination is not a ‘browser-reserved’ key: (Using ‘X’ which is a non-reserved accelerator key—at least in IE/ Firefox3.) 1. Scenario 1: down ALT, down x, up ALT, up x 2. Scenario 2: down ALT, down x, up x, up ALT 3. Scenario 4: down ALT, up ALT, down ALT, down x, up ALT, up x 4. Scenario 5: down ALT, up ALT, down ALT, down x, up x, up ALT In each of these scenarios, an ALT key up or down event is lost, resulting in an inconsistent pairing of down/up events for the web developer. When handing scenarios for “browser-reserved” accelerator keys, more key events are lost (including the simple ALT down/up pair repeated twice). It would be nice to specify (perhaps in an appendix) the behavior of browser-reserved accelerator key combinations and what should be expected. To help push the discussion along, I would like to propose two potential ideas (one is more drastic than the other): 1. Create a requirement that browsers emit proper ALT key sequences (up/down pairs) to the web page unless focus has shifted out of the web page itself—here we would need to try to define where to draw the line of when ALT is in focus and when it is not in focus related to browser-reserved accelerator actions. 2. Remove the emission of modifier key (e.g., Shift/Alt/etc.) events from the key identifiers set. Thus, pressing ALT (for example) would not emit any keyboard events until a corresponding key was pressed. The KeyboardEvent interface will continue to support the Boolean modifier key flags so that distinctions between a key + a modifier can be made by the web developer, but this will cut back and the number of events raised and eliminate the out-of- order key event problems (ALT down key down ALT up Key up versus ALT down key down key up ALT up). Of course, a side effect is that this outcome will also effectively remove the detection of single modifier key presses for use in web applications.
Re: DOM3 Events Telcon Minutes, 27 Feb 2008
On Wed, 27 Feb 2008 22:06:07 +0100, Doug Schepers [EMAIL PROTECTED] wrote: shepazu Resolution: remove multimousewheel, put additional dimensional delta values on mousewheel The reason we needed a new event is that mousewheel is not dispatched for anything but vertical scrolling and that authors are expecting it to be dispatched for vertical scrolling only. So then we figured we needed mousewheelx. But since you sometimes want to know about both directions a new event was thought of that was dispatched prior to those events, multimousewheel that would contain delta information for both directions. So unless there's evidence that all this is not needed I disagree with reverting the decision on how to deal with mousewheel events. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Extra Connection Support Proposal
Kris Zyp wrote: you click on a link, does the link get followed? That is the same sort of scenario, isn't it? At least firefox will abort any existing downloads for the current page when the user clicks a link. But if you're downloading these images in another tab you might have this problem yeah. Though if it's simply multiple images the new page will likely get squeezed in between two of the image downloads. And there is an important distinction between images being downloaded that consume connections and a long-lived response that consume a connection. With normal responses, two connection usually provides a means for relatively continuous utilization of resources. Most of the time two connections provide enough requests that the usually the server is processing a request, or a response is downloading. Either way, something is being done, and it is quite reasonable for further requests to be queued, since the server/connection is working to finish the response as fast as possible within it's capability. On the otherhand, when a long-lived response is paused indefinitely until a the server has a message to be sent, there is nothing being done. Nothing is being downloaded, and the server isn't working on anything, and requests can be queued indefinitely even though nothing is happening. Yup, it seems like people agree with this. It's just the proposal to put it as a feature on XHR that seems to be disliked by a few people, me included. Doing this on an HTTP level seems like the right solution to me. Though i'm not sure what working group would then be appropriate for standardizing it... / Jonas
Regarding my ACTION-249 for DOM L3 Events
Attached is V1 beta of the abstraction library (TestLib), and a page that uses
it.
So far the library provides:
1. Abstraction API for adding event listeners to objects x-browser
(tested on FF2/IE7/Saf3/O9.2 all on Windows platform).
/* TestLib -- Simple Testing Library
Abstracts common browser inconsistencies where the purpose of the test case does not depent on testing the given functionality
*/
// [global scope]
function TestLibrary() { }
// [TestLib scope] addEvent( [in] Object /* HTMLElement / HTMLDocument / Window */,
// [in] String /* event name */,
// [in] FunctionPointer /* JS function pointer variable */,
// [in] Bool /* useCapture (optional)*/ )
TestLibrary.prototype.addEvent = function (ob, name, func, capture)
{
if (!ob || (typeof ob != 'object'))
throw new Error(Call to TestLib.addEvent([ob], name, func, capture): Please provide the object (element, document, window) to which the event should be attached., Call to TestLib.addEvent: Please provide the object (element, document, window) to which the event should be attached.);
if (!name || (typeof name != 'string'))
throw new Error(Call to TestLib.addEvent(ob, [name], func, capture): Please provide the name of the event to attach (sans the 'on' prefix). For example: 'click' not 'onclick'., Call to TestLib.addEvent(ob, [name], func, capture): Please provide the name of the event to attach (sans the 'on' prefix). For example: 'click' not 'onclick'.);
if (!func || (typeof func != 'function'))
throw new Error(Call to TestLib.addEvent(ob, name, [func], capture): Please provide the function pointer to be called when the event is raised. For example: function () { ... }, Call to TestLib.addEvent(ob, name, [func], capture): Please provide the function pointer to be called when the event is raised. For example: function () { ... });
// Param 4 is optional. if specified it will be used--however, some browsers (IE) do not support the capture phase.
if (capture == undefined)
capture = false;
if (document.addEventListener)
return ob.addEventListener(name, func, capture);
else // IE special case
return ob.attachEvent(on + name, func);
}
var TestLib = new TestLibrary();Title: DOM Events API Test Suite - doubleclick-001
Row 1, Cell 1Row 1, Cell 2
Row 2, Cell 1Row 2, Cell 2
Row 3, Cell 1Row 3, Cell 2
Row 4, Cell 1Row 4, Cell 2
Row 5, Cell 1This Value should change as you double click on this table.
Re: Issue Request for DOM L3 Events
Hmm, i stand corrected, somehow i wasn't triggering 3/4, the S3/Win behaviour for ALT down, ALT up, ALT down, ALT up is KeyDown, KeyUp, KeyUp Which appears to be due to ALT activating the menu *sigh* --Oliver On Feb 27, 2008, at 1:39 PM, Oliver Hunt wrote: I think it's probably worth pointing out that the special handling of ALT is specific to Windows as ALT is used to activate menus, this does not effect MacOS, and may or may not effect the various linux browsers (i honestly have no idea what they do and don't have a linux system to test on). That said my (brief) testing of Safari for Windows shows that Safari correctly pair ALT up/down in all of the scenarios below. The testcase I used is at http://nerget.com/tests/input-testcase.html --Oliver On Feb 21, 2008, at 1:09 PM, Travis Leithead wrote: I’d like to propose a discussion about the handling of the ALT + key combination that will hopefully end in a normative requirement. In observing IE as well as other browsers, there is “good” x- browser consistency between the handling of ALT and pressing a modifier key. While the browsers are mostly consistent, they do so in a way that is not very reliable for web developers because key down/key up pairs are often not respected (key events get dropped in some scenarios). I’ve identified the following scenarios that we can discuss: Scenarios for ALT handling where the key combination is not a ‘browser-reserved’ key: (Using ‘X’ which is a non-reserved accelerator key—at least in IE/ Firefox3.) 1. Scenario 1: down ALT, down x, up ALT, up x 2. Scenario 2: down ALT, down x, up x, up ALT 3. Scenario 4: down ALT, up ALT, down ALT, down x, up ALT, up x 4. Scenario 5: down ALT, up ALT, down ALT, down x, up x, up ALT In each of these scenarios, an ALT key up or down event is lost, resulting in an inconsistent pairing of down/up events for the web developer. When handing scenarios for “browser-reserved” accelerator keys, more key events are lost (including the simple ALT down/up pair repeated twice). It would be nice to specify (perhaps in an appendix) the behavior of browser-reserved accelerator key combinations and what should be expected. To help push the discussion along, I would like to propose two potential ideas (one is more drastic than the other): 1. Create a requirement that browsers emit proper ALT key sequences (up/down pairs) to the web page unless focus has shifted out of the web page itself—here we would need to try to define where to draw the line of when ALT is in focus and when it is not in focus related to browser-reserved accelerator actions. 2. Remove the emission of modifier key (e.g., Shift/Alt/etc.) events from the key identifiers set. Thus, pressing ALT (for example) would not emit any keyboard events until a corresponding key was pressed. The KeyboardEvent interface will continue to support the Boolean modifier key flags so that distinctions between a key + a modifier can be made by the web developer, but this will cut back and the number of events raised and eliminate the out-of- order key event problems (ALT down key down ALT up Key up versus ALT down key down key up ALT up). Of course, a side effect is that this outcome will also effectively remove the detection of single modifier key presses for use in web applications.
Re: Extra Connection Support Proposal
Doing this on an HTTP level seems like the right solution to me. Though i'm not sure what working group would then be appropriate for standardizing it... I don't mind trying this avenue, I just fear that this is even more likely to be a dead-end. HTTP is already very complicated (it would seem more so than XHR to me) and is much more solidified and it seems unlikely that there would a be solution down that path. And I don't see how it is any more right for this to be done in HTTP, The user agent needs to be informed by something, and I don't see a clear distinction in why it is superior to be informed by the HTTP response rather than API/author since this doesn't really affect the actual HTTP communication protocol, but when a user agent chooses to use an (additional) HTTP communication channel. I am concerned that if all parties continually come up with really good reasons to keep deferring this to someone else, the user with hanging requests still lose. I am going to send out another proposal that will hopefully be more palatable/feasible. Thanks, Kris
Re: Extra Connection Support Proposal
On Wed, 27 Feb 2008 23:48:47 +0100, Kris Zyp [EMAIL PROTECTED] wrote: I am going to send out another proposal that will hopefully be more palatable/feasible. I don't want this in XMLHttpRequest. It makes no sense that only XMLHttpRequest would benefit from this. That doesn't help video, lots of external style sheets, images, etc. We need something helps all those APIs. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[XHR2] Editorial:
When the s teps for the send() method say to make upload progress notifications user agents must, if the request entity body is not empty and async is s teps -- steps Also you might wish to change your mailto link so the [XHR2] at the start of the subject line is automatic. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
