Re: [whatwg] HTTP status code from JavaScript
I like the `window.http` idea mentioned earlier by Michael. Something like:
```js
window.http = {
url: window.location.href,
status: 404,
headers: {
/* ... */
}
};
```
If implemented, this would also be easy to polyfill in older browsers using
the duplicate AJAX request hack that Michael is using today (or a
server-side generated inline script block if you want guaranteed
correctness).
Sincerely,
James Greene
Sent from my [smart?]phone
On May 26, 2014 6:37 PM, "Michael Heuberger" <
michael.heuber...@binarykitchen.com> wrote:
> Yeah, something like that Austin.
>
> But like I mentioned, why add the status code inside the HTML code when
> it's already available in the HTTP status header? Hence I raised
> "redundancy" multiple times before.
>
> I could do that but not thanks. I still believe that JavaScript should
> be able to parse the HTTP status headers.
>
> Cheers
> Michael
>
> On 27/05/14 00:16, Austin France wrote:
> > Hi from Random Observer
> >
> > Just trying to get my head around the requirement:-
> >
> > So we have an app that is served for any URL on the server (and so
> > apart from the small html loader is only loaded for the initial
> > request) and from that the server checks for the presence of the video
> > and either returns a status 200 or 404 plus the app code which the
> > javascript wants to use to display a video not available message or
> > the video itself. The URI of the video presumably being derived from
> > the URI of the page (not by anything passed by the server).
> >
> > The requirement is to be able to indicate to the app that the video
> > does not exist in the initial request without requiring any additional
> > informationt be passed to the client.
> >
> > Having the status code available to javascript though would obviously
> > be ideal in this kind of setup, however as each URI is still returning
> > some html and I think the meta tag or body attribute suggestions
> > previously mentioned a completely acceptable way to solve this issue
> > (or variation of), I see it as a minor overhead.
> > sort of thing.
> >
> >
> >
> >
> > Regards
> > Austin
> >
> >
> >
> >
> > On 26 May 2014 12:09, David Bruant > <mailto:bruan...@gmail.com>> wrote:
> >
> > Le 26/05/2014 01:52, Michael Heuberger a écrit :
> >
> > Serving different content based on
> > different URLs (and status)
> > actually does make a lot of sense when you
> > want your user to see the
> > proper content within the first HTTP
> > round-trip (which saves
> > bandwidth). If you always serve generic
> > content and figure it all out
> > on the client side, then either you always
> > need a second request to
> > get the specific content or you're always
> > sending useless data during
> > the first generic response which is also
> > wasted bandwidth.
> >
> > Good point. From that point of view I agree
> > but you forgot one thing:
> > The user experience. We want mobile apps to be
> > very responsive below
> > 300ms.
> >
> > Agreed (on UX and responsive applications)
> >
> > Hence the two requests. The first one ensures
> > the SPA to be
> > loaded and the UI to be initialized. You'll
> > see some animation, a text
> > saying "Fetching data" whatever. Then the
> > second request retrieves the
> > specific content.
> >
> > What I'm proposing is that all the relevant
> > content is served within
> > the *first* request. The URL is used by the client
> > to express to the
> > server (with arbitrary granularity, it depends on
> > your app, obviously)
> > what the user wants.
> >
Re: [whatwg] HTTP status code from JavaScript
I think he wants to be able to serve the exact same single page no matter what the status code is (i.e. including `404`s) and then be able to react to the initial page status code on the client-side. A bit of an edge case as most people serve different pages with HTTP errors but it is a logical use case. Sincerely, James Greene On Fri, May 23, 2014 at 3:33 AM, Silvia Pfeiffer wrote: > I had to deal with this on a script created IMG element the other day. I > used onerror to deal with it. > For xmlhttprequest you can use the status field. > Why is that not enough? > > Silvia. > On 23 May 2014 18:06, "Michael Heuberger" < > michael.heuber...@binarykitchen.com> wrote: > > > Good points Mat > > > > In theory you have good points but in the real world it is more > > complicated than that. See my comments below: > > > > On 23/05/14 19:49, Mat Carey wrote: > > >> - Notify the administrator about a 404 by email with a response back > to > > >> the server > > > But the server already knows about the 404, JS shouldn’t be needed/used > > to re-inform the server of the status it’s already sent. > > > > Nowadays you can access other entities directly, i.E. a RIAK Database > > server which returns a 404 if the ID in the query does not exist which > > can be a raw HTTP request. This without any app logic in-between. > > > > ... or you have a cloud with multiple servers but only one of them is > > responsible for error reporting. > > > > It is just an example. I could count more use cases where the feature is > > really needed. > > > > >> - Display a beautiful 404 page and hide parts of the navigation > > >> - Reveal navigation history to give users a better usability > experience > > >> during 404s > > >> - And many more … > > > I agree with those entirely but couldn’t they also be achieved by > > including the correct scripts on the 404 page issued from the server? > > > > No, it is a single page app. All the HTML templates are on the client > > side and loaded once during page load. And everything happens > > dynamically. In other words: You load everything once, then there is no > > further interaction with the server unless it's a specific query for > > data or alters data in the database. > > > > Furthermore you can convert a whole single page app into an iPhone app > > with PhoneGap. All the HTML resides in the app, not on the server. > > That's a very different approach and a good reason why JavaScript has > > the right to know if the HTTP request resulted into a 200 or a 404. > > > > Cheers > > Michael > > > > > > > > (I’m not against the original suggestion, I just don’t think these > > particular use-cases demand a new feature) > > > > > > Mat Carey > > > 07952258096 > > > > > > On 23 May 2014, at 07:52, Michael Heuberger < > > michael.heuber...@binarykitchen.com> wrote: > > > > > >> Hi Julian > > >> > > >> Yes, with "AJAX" requests I meant using XMLHTTPRequest. > > >> > > >>> If the initial page load yields a 404 will there be any scripts to > > >>> execute at all? > > >> Oh yes, absolutely. Have you ever written a single page app? There is > > >> lots of logic to execute when a 404 occurs. I could count plenty of > use > > >> cases and functions that make sense. Here some examples: > > >> - Notify the administrator about a 404 by email with a response back > to > > >> the server > > >> - Display a beautiful 404 page and hide parts of the navigation > > >> - Reveal navigation history to give users a better usability > experience > > >> during 404s > > >> - And many more ... > > >> > > >> All these above examples run on JavaScript. Because there is currently > > >> no way for JavaScript to determine if the page load yielded a 404, a > > >> subsequent request, namely a XMLHTTPRequest one is often added. In my > > >> professional opinion a bad solution. > > >> > > >> Again, I strongly believe that this would be a huge improvement and > > >> avoids unnecessary network traffic. > > >> > > >> Cheers > > >> Michael > > >> > > >> -- > > >> > > >> Binary Kitchen > > >> Michael Heuberger > > >> 4c Dunbar Road > > >> Mt Eden > > >> Auckland 1024 > > >> (New Zealand) > > >> > > >> Mobile (text only) ... +64 21 261 89 81 > > >> Email mich...@binarykitchen.com > > >> Website .. http://www.binarykitchen.com > > >> > > > > -- > > > > Binary Kitchen > > Michael Heuberger > > 4c Dunbar Road > > Mt Eden > > Auckland 1024 > > (New Zealand) > > > > Mobile (text only) ... +64 21 261 89 81 > > Email mich...@binarykitchen.com > > Website .. http://www.binarykitchen.com > > > > >
Re: [whatwg] HTTP status code from JavaScript
I'm not opposed to this idea but... what Is a realistic use case for this? Sincerely, James Greene On Thu, May 22, 2014 at 10:36 PM, Michael Heuberger < michael.heuber...@binarykitchen.com> wrote: > Hello WhatWG > > There is a need to obtain the HTTP status code for the page itself from > JavaScript: > https://bugzilla.mozilla.org/show_bug.cgi?id=999886 > > I think this would be a great feature to save additional traffic in an > already congested internet. Because I see lots of queries made by > XMLHttpRequest solely to obtain the HTTP status code of the same URL. > > If the global browser variable (JavaScript) would already hold the > status code, then these queries would become obsolete and the internet > becomes a bit less blocked. > > Let me know how to proceed with my proposal within WhatWG. > > Greetings from Auckland, > Michael > > -- > > Binary Kitchen > Michael Heuberger > 4c Dunbar Road > Mt Eden > Auckland 1024 > (New Zealand) > > Mobile (text only) ... +64 21 261 89 81 > Email mich...@binarykitchen.com > Website .. http://www.binarykitchen.com > >
Re: [whatwg] Proposal: navigator.cores
If we're going to choose a name that abstracts the implementation details (and rightly so), why not just go with `navigator.concurrency`? Sincerely, James Greene Sent from my [smart?]phone On May 4, 2014 8:50 AM, "Adam Barth" wrote: > On Sun, May 4, 2014 at 12:13 AM, Tobie Langel >wrote: > > > On May 4, 2014, at 7:45, Rik Cabanier wrote: > > > On Sat, May 3, 2014 at 10:32 PM, Eli Grey wrote: > > > > > >> The proposal specifically states using logical cores, which handles > > >> all of the CPUs you mentioned properly. > > >> > > >> Intel CPUs with hyperthreading enabled report logical cores as double > > >> the hardware cores. Depending on the version and configuration of the > > >> Samsung Exynos Octa big.LITTLE CPUs, you will get either 4 logical > > >> cores (only one cluster can run at a time) or 8 logical cores > > >> (big.LITTLE MP, available in Exynos 5420 or later only). > > >> > > > > > > Great! > > > Make sure this is captured when it is put in a specification. > > > Otherwise the subtlety between an actual and a logical core might get > > lost. > > > > Shouldn't this also be captured in the API's name? > > > > Maybe navigator.hardwareConcurrency as a nod to the C++11 name? > > Adam >
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
> > There's no perf boost available for searching by id on an arbitrary > element. The reason you may get a better perf for the normal > functions is that documents cache a map from id->element on > themselves, so you just have to do a fast hash-lookup. Arbitrary > elements don't have this map (it would be way too much memory cost), > so it'll fall back to a standard tree search, exactly as a > querySelector would. Hmm, I suppose that makes sense. Bummer. Thanks for the concise explanation! Sincerely, James Greene On Fri, Oct 18, 2013 at 2:11 PM, Tab Atkins Jr. wrote: > On Fri, Oct 18, 2013 at 11:09 AM, James Greene > wrote: > > I would also love to see `getElementById` added to the > HTMLElement/Element > > interface. It would be nice to capitalize on that potential perf boost in > > jQuery as well. > > There's no perf boost available for searching by id on an arbitrary > element. The reason you may get a better perf for the normal > functions is that documents cache a map from id->element on > themselves, so you just have to do a fast hash-lookup. Arbitrary > elements don't have this map (it would be way too much memory cost), > so it'll fall back to a standard tree search, exactly as a > querySelector would. > > ~TJ >
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
>
> Personally I'd vote for it being possible to search any object for an id,
> never mind it having to be part of the DOM or attached to a fragment. How
> about:
> tbodyPtr.getElementById (id);
I would also love to see `getElementById` added to the HTMLElement/Element
interface. It would be nice to capitalize on that potential perf boost in
jQuery as well.
Sincerely,
James Greene
On Fri, Oct 18, 2013 at 12:47 PM, Ryosuke Niwa wrote:
> On Oct 18, 2013, at 5:22 AM, Tim Streater wrote:
>
> > On 15 Oct 2013 at 01:18, Glenn Maynard wrote:
> >
> >> On Thu, Oct 10, 2013 at 1:41 PM, Ian Hickson wrote:
> >
> > [snip]
> >
> >>> document.getElementById(id)
> >>>
> >>> ...becomes:
> >>>
> >>> document.querySelector('#' + escapeCSSIdent(id))
> >>>
> >>> ...which is a lot less pretty and understandable, especially when you
> >>> consider that many authors are actually coming from:
> >>>
> >>> document.all[id]
> >>>
> >>> ...which is briefer than either, and still self-explanatory.
> >>>
> >>>
> >>> I feel this is a case where we're not putting authors first, but are
> >>> instead putting spec purity first.
> >
> >> (Nothing about this discussion relates to "spec purity", whatever that
> >> means. My argument is that this function is useless legacy, and that
> >> proliferating it to DocumentFragment seems to be for consistency's sake
> >> only.)
> >
> > It's not useless legacy, it's a simple API call that does what it says.
> >
> > I have an array of table bodies, one of which I switch into the user's
> view by unhooking the present one from the table and appendChild-ing the
> one the user now wants to look at. It's irritating enough that to search
> one of these tBodies for an id I have to temporarily hook it to a
> DocumentFragment without then being forced to use an opaque API call to get
> the result I want.
> >
> > Personally I'd vote for it being possible to search any object for an
> id, never mind it having to be part of the DOM or attached to a fragment.
> How about:
> >
> >tbodyPtr.getElementById (id);
> >
> > That might be too radical so I'd settle for getElementById and friends
> being available on fragments. Then we'd have consistency.
>
> I'm fine with exposing getElementById on DocumentFragment or on ShadowRoot
> because it returns exactly one element.
>
> What I'm opposed to is exposing getElementsByTagName, etc... because they
> return a live HTMLCollection. HTMLCollection is a horrible mess, and the
> use of it should be discouraged as much as possible.
>
> - R. Niwa
>
>
Re: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll
Aww, accidentally did a direct reply instead of replying to the list. :(
On Sep 18, 2013 7:01 AM, "James Greene" wrote:
> var q = document.querySelector;
> var qq = document.querySelectorAll;
> On Sep 18, 2013 3:14 AM, "Leon Gilyadov" wrote:
>
>> *The problem:*
>> document.querySelector and document.querySelectorAll
>> are long and used a lot.
>>
>> Lines in the code are long.
>>
>> *Proposal:*
>> q('.my-div')
>> will be equal to:
>> document.querySelector('.my-div)
>>
>> qq('.my-div')
>> will be equal to:
>> document.querySelectorAll('.my-div')
>>
>>
>> --Leon Gilyadov.
>>
>
Re: [whatwg] iterators intead of live NodeLists WAS: Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
I think it makes sense, too. That said, if the goal is to REPLACE the
NodeIterator and TreeWalker APIs completely, it wouldn't be all that
valuable for me as my most common use case has always been to get TEXT
NODES from under a root node based on some CSS filtering of its ancestor
nodes. If the proposed API used only CSS query selectors without also
allowing the additional NodeType filtering provided "whatToShow", then it
could not not be used to directly gather text nodes.
Might be OK to leave text nodes out... not sure how others use NIs/TWs.
Sincerely,
James Greene
On Jul 28, 2013 11:24 AM, "Tab Atkins Jr." wrote:
> I strongly agree with the use-case, and think some feature for this
> would be very helpful.
>
> [Mixing up your emails for reply convenience.]
> On Sat, Jul 27, 2013 at 11:25 AM, Ojan Vafai wrote:
> > On Sat, Jul 27, 2013 at 10:58 AM, Ojan Vafai wrote:
> >> var iterator = document.querySelectorAll('div').iterator(); <--- does
> some
> >> magic to not precompute the whole list
>
> Can you describe this magic? It would be nice if this were somehow
> possible, but I'm not sure how it would be.
>
> > There are many places where we expose Sequence or NodeList that
> can't
> > easily be replaced with hand-rolled DOM walking (e.g. getNamedFlows).
> >
> > You could imagine NodeIterator taking a Sequence/NodeList as an
> > argument to it's constructor instead of adding an iterator method, but I
> > find the NodeIterator interface to be clunky and awkward.
>
> Yeah, having the ability to produce these iterators for any of the
> currently-static Node lists would be great. But again, not sure how
> the magic would work. :/
>
> >> while (let current = iterator.next()) { ... }
> >>
> >> And next always does the walk from the current node. So, if you add a
> div
> >> before the current node, this specific iterator won't hit it, but if you
> >> add a div after it would. I'm not sure what should happen though if you
> >> remove the node that's the current node. I think I'm OK with the
> iterator
> >> just returning null for the next() call in that case.
> >>
> >
> > Thinking more on this, I think we could make next() still work in the
> case
> > where you remove the node by pointing current at the previous node in the
> > tree. Then you could do things like:
> >
> > while (let current = iterator.next()) { current.remove(); }
>
> This should be an ES iterator, rather than a custom DOM thing that
> looks almost exactly like an ES iterator.
>
> > I think the methods we'd want here are next, previous, first and last.
> That
> > way you can walk the iterator forward or backward. This doesn't overlap
> > well with NodeIterator's current API.
>
> How useful is it to be able to walk an iterator in both directions at
> the same time? I suppose we can produce an iterator subclass that
> also has the additional methods we want.
>
> ~TJ
>
Re: [whatwg] iterators intead of live NodeLists WAS: Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
Isn't that what the NodeIterator and TreeWalker APIs are for?
Sincerely,
James Greene
On Jul 27, 2013 1:25 PM, "Ojan Vafai" wrote:
> Realized this should probably be a new thread...
>
>
> On Sat, Jul 27, 2013 at 10:58 AM, Ojan Vafai wrote:
>
> > On Thu, Jul 25, 2013 at 1:42 PM, Jonas Sicking wrote:
> >
> >> On Thu, Jul 25, 2013 at 9:05 AM, Boris Zbarsky
> wrote:
> >> > On 7/24/13 10:42 PM, Jussi Kalliokoski wrote:
> >> >>
> >> >> Argh, I had forgotten about live NodeLists. OK, this is a reason that
> >> >> resonates with me and justifies calling these methods obsolete. Too
> bad
> >> >> these methods are so badly flawed
> >> >
> >> >
> >> > Fwiw, I think the performance impact of live NodeLists is ... unclear.
> >> Their
> >> > existence does mean that you have to deal with DOM mutations changing
> >> the
> >> > lists, but them being live also means you can make the list getters
> much
> >> > faster in cases when the caller doesn't actually want the entire list.
> >>
> >> And, as importantly, it also means that for multiple consecutive calls
> >> to get the list, say inside of a loop, can return the same result
> >> object. I.e. you don't have to re-walk the DOM for every iteration
> >> through the loop.
> >>
> >
> > I think these are good points of what is lost by using static NodeLists.
> I
> > still feel pretty strongly though that these benefits don't outweigh the
> > costs. If we want to give people most of the benefits of live NodeLists
> > without the costs we could expose an iterator API:
> >
> > var iterator = document.querySelectorAll('div').iterator(); <--- does
> some
> > magic to not precompute the whole list
> > while (let current = iterator.next()) { ... }
> >
> > And next always does the walk from the current node. So, if you add a div
> > before the current node, this specific iterator won't hit it, but if you
> > add a div after it would. I'm not sure what should happen though if you
> > remove the node that's the current node. I think I'm OK with the iterator
> > just returning null for the next() call in that case.
> >
>
> Thinking more on this, I think we could make next() still work in the case
> where you remove the node by pointing current at the previous node in the
> tree. Then you could do things like:
>
> while (let current = iterator.next()) { current.remove(); }
>
> This gets the performance benefits of live NodeLists, I think meets the
> > main use-cases of not wanting to walk the whole DOM, but doesn't require
> > the browser to do a lot of metadata tracking as you go.
> >
> > Ojan
> >
>
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
Isn't that what the NodeIterator and TreeWalker DOM APIs were for?
Sincerely,
James Greene
On Jul 27, 2013 12:58 PM, "Ojan Vafai" wrote:
> On Thu, Jul 25, 2013 at 1:42 PM, Jonas Sicking wrote:
>
> > On Thu, Jul 25, 2013 at 9:05 AM, Boris Zbarsky wrote:
> > > On 7/24/13 10:42 PM, Jussi Kalliokoski wrote:
> > >>
> > >> Argh, I had forgotten about live NodeLists. OK, this is a reason that
> > >> resonates with me and justifies calling these methods obsolete. Too
> bad
> > >> these methods are so badly flawed
> > >
> > >
> > > Fwiw, I think the performance impact of live NodeLists is ... unclear.
> > Their
> > > existence does mean that you have to deal with DOM mutations changing
> the
> > > lists, but them being live also means you can make the list getters
> much
> > > faster in cases when the caller doesn't actually want the entire list.
> >
> > And, as importantly, it also means that for multiple consecutive calls
> > to get the list, say inside of a loop, can return the same result
> > object. I.e. you don't have to re-walk the DOM for every iteration
> > through the loop.
> >
>
> I think these are good points of what is lost by using static NodeLists. I
> still feel pretty strongly though that these benefits don't outweigh the
> costs. If we want to give people most of the benefits of live NodeLists
> without the costs we could expose an iterator API:
>
> var iterator = document.querySelectorAll('div').iterator(); <--- does some
> magic to not precompute the whole list
> while (let current = iterator.next()) { ... }
>
> And next always does the walk from the current node. So, if you add a div
> before the current node, this specific iterator won't hit it, but if you
> add a div after it would. I'm not sure what should happen though if you
> remove the node that's the current node. I think I'm OK with the iterator
> just returning null for the next() call in that case.
>
> This gets the performance benefits of live NodeLists, I think meets the
> main use-cases of not wanting to walk the whole DOM, but doesn't require
> the browser to do a lot of metadata tracking as you go.
>
> Ojan
>
Re: [whatwg] Stack trace in window.onerror
Ian —
So Paul Irish pointed out to me that the spec has just been updated to
include this:
http://html5.org/tools/web-apps-tracker?from=8085&to=8086
Yay, that's awesome! :)
*Two things:*
*
*
*#1.*
My last name ends with an 'e' ('Greene' vs. 'Green'). Please correct that
when you get a chance. Thanks!
*#2.*
You had mentioned earlier that there is already a window 'error' event that
can be listened to via `window.addEventListener('error', fn, false);` if
you don't use `window.onerror = fn;`:
There's already an event. You can get it if you use addEventListener()
for 'error'
> rather than using onerror.
(It's also exposed on the event object, for those of you using
addEventListener()
> for error events rather than onerror.)
Is that clarified in the spec somewhere already? Although that makes
perfect sense to me, I have never noticed it before nor heard of any
browser vendors implementing such. Have there been any such
implementations yet? If so, that's *wonderful* news. :)
Sincerely,
James Greene
On Wed, Jul 24, 2013 at 4:27 PM, James Greene wrote:
> Rick —
> Thanks for clarifying/correcting both my comment and Hixie's!
>
> Sincerely,
> James Greene
>
>
>
> On Wed, Jul 24, 2013 at 4:24 PM, Rick Waldron wrote:
>
>> On Wed, Jul 24, 2013 at 2:50 PM, Ian Hickson wrote:
>>
>> > On Fri, 12 Jul 2013, James Greene wrote:
>> > > On Fri, Jul 12, 2013 at 12:17 PM, Ian Hickson wrote:
>> > > > On Tue, 5 Feb 2013, Nathan Broadbent wrote:
>> > > > >
>> > > > > The current information passed to window.onerror rarely provides
>> > > > > sufficient information to find the cause of the error. The column
>> > > > > number argument will be a big step forward, but a stack trace
>> would
>> > > > > be especially useful. I would like to add my support for improving
>> > > > > the window.onerror arguments, with a fifth argument for stack
>> trace.
>> > > > > Is there anything that James or I could do to move this discussion
>> > > > > along?
>> > > >
>> > > > This seems useful, but I don't think it's specific to
>> window.onerror.
>> > > > I would recommend approaching the es-discuss list about this.
>> > >
>> > > I'm curious: would do you say that? All evergreen browsers already
>> > > include a `stack` property on their core `Error` prototypes, so it
>> seems
>> > > to me that the only thing preventing us from getting that useful
>> > > information for unhandled errors is the fact that `window.onerror`
>> does
>> > > not provide us with a real Error object instances (or even fake ones
>> > > with shell properties in the case of cross-domain errors).
>> >
>> > Ah, I was unaware of Error.stack. Interesting!
>> >
>>
>> There is no static property with the name "stack" on the [[Global]]
>> built-in Error object, nor is the property added to Error.prototype. In
>> v8,
>> SpiderMonkey and JSC, the stack property appears on the actual instance
>> object initialized by Error.
>>
>>
>>
>> Rick
>>
>
>
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
While I'm not familiar with the spec for DocumentFragments, I've always consider them to be more equivalent to a detached element node than a document node. Keeping that interpretation in mind, adding these methods wouldn't make sense to me personally. Unless my understanding is completely off-base and fragments *are* supposed to be most similar to document nodes, I'd agree with the earlier suggestion that those who want this functionality should just add it themselves via JS. Sincerely, James Greene On Wed, Jul 24, 2013 at 7:39 PM, Ryosuke Niwa wrote: > > On Jun 28, 2013, at 5:32 PM, Zirak A wrote: > > > But that's a bit looking at it backwards. Selectors are supposed to be an > > abstraction over these methods, not the other way around. > > No. > > > The point here is that document fragments are documents - so they should > have a consistent API. > > No. > > > Adding this isn't about "backwards compatibility" or anything of the > sort. It's > > adding methods that people already use, because as said, not everyone > uses > > selectors (and not just because of browser-compat). > > getElementById is okay but we want to discourage authors from using > methods like getElementsByTagName and getElementsByClassName that return > live NodeList objects. They incur a lot of implementation cost in WebKit > and hurts the DOM performance. e.g. whenever there is a LiveNode list > somewhere in a document, WebKit walks up all ancestors of an inserted or > removed element to clear their live node lists' caches. > > On Jun 29, 2013, at 3:47 PM, Glenn Maynard wrote: > > > On Sat, Jun 29, 2013 at 4:55 PM, Tim Streater > wrote: > > > >> But what I'm doing, I'm not doing for CSS purposes. I'm trying to find a > >> particular row, by id, in order to modify the contents of cells in that > >> row. I find it perverse to be using a style-related API call to do that. > >> > > > > CSS uses selectors, not the other way around. querySelector() has > nothing > > to do with styles. > > Indeed. Note that querySelector implementations in WebKit and Blink > optimize #foo, .foo, etc... so that they're equally if not faster than > getElementsById, getElementsByClassName, etc... > > - R. Niwa > >
Re: [whatwg] Stack trace in window.onerror
Rick — Thanks for clarifying/correcting both my comment and Hixie's! Sincerely, James Greene On Wed, Jul 24, 2013 at 4:24 PM, Rick Waldron wrote: > On Wed, Jul 24, 2013 at 2:50 PM, Ian Hickson wrote: > > > On Fri, 12 Jul 2013, James Greene wrote: > > > On Fri, Jul 12, 2013 at 12:17 PM, Ian Hickson wrote: > > > > On Tue, 5 Feb 2013, Nathan Broadbent wrote: > > > > > > > > > > The current information passed to window.onerror rarely provides > > > > > sufficient information to find the cause of the error. The column > > > > > number argument will be a big step forward, but a stack trace would > > > > > be especially useful. I would like to add my support for improving > > > > > the window.onerror arguments, with a fifth argument for stack > trace. > > > > > Is there anything that James or I could do to move this discussion > > > > > along? > > > > > > > > This seems useful, but I don't think it's specific to window.onerror. > > > > I would recommend approaching the es-discuss list about this. > > > > > > I'm curious: would do you say that? All evergreen browsers already > > > include a `stack` property on their core `Error` prototypes, so it > seems > > > to me that the only thing preventing us from getting that useful > > > information for unhandled errors is the fact that `window.onerror` does > > > not provide us with a real Error object instances (or even fake ones > > > with shell properties in the case of cross-domain errors). > > > > Ah, I was unaware of Error.stack. Interesting! > > > > There is no static property with the name "stack" on the [[Global]] > built-in Error object, nor is the property added to Error.prototype. In v8, > SpiderMonkey and JSC, the stack property appears on the actual instance > object initialized by Error. > > > > Rick >
Re: [whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)
I'd love that! Perhaps similar to what Node.js did with their `uncaughtException` event <http://nodejs.org/api/process.html#process_event_uncaughtexception>? Sincerely, James Greene On Fri, Jul 12, 2013 at 1:40 PM, Elliott Sprehn wrote: > Can we just add a new event that takes an event object instead of a huge > list of arguments? :) > > > On Fri, Jul 12, 2013 at 11:30 AM, James Greene > wrote: > >> I'd rather get an Error-like duck-typed object with this shell info for >> cross-domain requests than to not get a real Error object when the >> unhandled error *is* from the same origin. >> >> Adding the trace as another new argument to `window.onerror` is certainly >> an option but the parameter list is getting long and I suspect that Error >> prototypes may still gain additional properties in the future. Continuing >> down this path of adding more parameters rather than just passing an Error >> instance or Error-like object (or providing a separate supplemental method >> like `window.getLastError()` seems like one of those decisions that might >> results in infinite sadness in the future. >> >> Sincerely, >> James Greene >> >> >> >> On Mon, Mar 11, 2013 at 5:50 AM, Simon Pieters wrote: >> >>> On Tue, 05 Feb 2013 08:20:27 +0100, Elliott Sprehn >>> wrote: >>> >>> On Mon, Feb 4, 2013 at 5:44 PM, Oliver Hunt wrote: >>>> >>>> ... >>>>> That's tricky - what is your "stack trace"? You can very easily end up >>>>> leaking private information across frames. >>>>> >>>>> >>>>> window.onerror is triggered across non-same origin frames? >>>> >>> >>> Yes, but always with these arguments: >>> >>> "Script error.", "", 0, 0 >>> >>> -- >>> Simon Pieters >>> Opera Software >>> >> >> >
Re: [whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)
I'd rather get an Error-like duck-typed object with this shell info for cross-domain requests than to not get a real Error object when the unhandled error *is* from the same origin. Adding the trace as another new argument to `window.onerror` is certainly an option but the parameter list is getting long and I suspect that Error prototypes may still gain additional properties in the future. Continuing down this path of adding more parameters rather than just passing an Error instance or Error-like object (or providing a separate supplemental method like `window.getLastError()` seems like one of those decisions that might results in infinite sadness in the future. Sincerely, James Greene On Mon, Mar 11, 2013 at 5:50 AM, Simon Pieters wrote: > On Tue, 05 Feb 2013 08:20:27 +0100, Elliott Sprehn > wrote: > > On Mon, Feb 4, 2013 at 5:44 PM, Oliver Hunt wrote: >> >> ... >>> That's tricky - what is your "stack trace"? You can very easily end up >>> leaking private information across frames. >>> >>> >>> window.onerror is triggered across non-same origin frames? >> > > Yes, but always with these arguments: > > "Script error.", "", 0, 0 > > -- > Simon Pieters > Opera Software >
Re: [whatwg] Stack trace in window.onerror
Ian — I'm curious: would do you say that? All evergreen browsers already include a `stack` property on their core `Error` prototypes, so it seems to me that the only thing preventing us from getting that useful information for unhandled errors is the fact that `window.onerror` does not provide us with a real Error object instances (or even fake ones with shell properties in the case of cross-domain errors). If I'm mistaken, please clarify. Thanks! Sincerely, James Greene On Fri, Jul 12, 2013 at 12:17 PM, Ian Hickson wrote: > On Tue, 5 Feb 2013, Nathan Broadbent wrote: > > > > The current information passed to window.onerror rarely provides > > sufficient information to find the cause of the error. The column number > > argument will be a big step forward, but a stack trace would be > > especially useful. I would like to add my support for improving the > > window.onerror arguments, with a fifth argument for stack trace. Is > > there anything that James or I could do to move this discussion along? > > This seems useful, but I don't think it's specific to window.onerror. I > would recommend approaching the es-discuss list about this. > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Re: [whatwg] Proposing: "autoscroll" event
*Oh, another option:* As long as the element does not have CSS styles applied via an ID selector, you could just change the element ID temporarily rather than visually hiding it in order to avoid the reflows. Sincerely, James Greene On Wed, Jun 12, 2013 at 12:20 PM, James Greene wrote: > Although it may (will?) incur additional reflows, here's a short term hack: > >1. On "DOMContentLoaded" (or equivalent), sniff the element ID from the > hash and visually hide that element. This will prevent the browser from > auto-scrolling. >2. On "load", visually show that element again and then scroll to it > (or not, up to you). > > > Sincerely, > James Greene > > > > On Tue, May 14, 2013 at 4:44 PM, Glenn Maynard wrote: > >> On Tue, May 14, 2013 at 5:01 PM, Nils Dagsson Moskopp < >> n...@dieweltistgarnichtso.net> wrote: >> >> > The simplest solution (by far) would be to stop storing “information >> > that is used by JS” in a hash. Even Internet Explorer has pushState() >> > these days: <http://caniuse.com/history>. >> > >> >> Web APIs have to deal with how things are actually used, not how you wish >> they were. Storing state in the hash is a reality. >> >> Additionally, pushState does not replace storing state in the hash, nor >> was >> it intended to. >> >> -- >> Glenn Maynard >> > >
Re: [whatwg] Proposing: "autoscroll" event
Although it may (will?) incur additional reflows, here's a short term hack: 1. On "DOMContentLoaded" (or equivalent), sniff the element ID from the hash and visually hide that element. This will prevent the browser from auto-scrolling. 2. On "load", visually show that element again and then scroll to it (or not, up to you). Sincerely, James Greene On Tue, May 14, 2013 at 4:44 PM, Glenn Maynard wrote: > On Tue, May 14, 2013 at 5:01 PM, Nils Dagsson Moskopp < > n...@dieweltistgarnichtso.net> wrote: > > > The simplest solution (by far) would be to stop storing “information > > that is used by JS” in a hash. Even Internet Explorer has pushState() > > these days: <http://caniuse.com/history>. > > > > Web APIs have to deal with how things are actually used, not how you wish > they were. Storing state in the hash is a reality. > > Additionally, pushState does not replace storing state in the hash, nor was > it intended to. > > -- > Glenn Maynard >
Re: [whatwg] Proposing: "autoscroll" event
So, to that end, what about just adjusting the spec for the "hashchange" event to also fire when the page is initially loaded if the URL contains a fragment identifier (hash)? The other scenarios mentioned would already be covered by the "hashchange" event. Sincerely, James Greene On Tue, May 14, 2013 at 12:48 PM, Kyle Simpson wrote: > > when should autoscroll be called? only after a url with a hash is > clicked in the same page? when following a link to a : url#specific_hash? > both cases? > > I initially conceived it as only firing on initial page load for a > URL#hash, so definitely that case. But I can also see how it might be > useful to listen for such events even when clicking within the same > document, so I'd certainly entertain that addition. :) > > > --Kyle > > > >
Re: [whatwg] Proposing: "autoscroll" event
I love that idea! Sincerely, James Greene On Mon, May 13, 2013 at 9:53 PM, Kyle Simpson wrote: > Increasingly, sites are doing client-side rendering at page load time, > which is breaking the (useful) functionality of being able to have a #hash > on a URL that auto-scrolls the page to make some element visible after > page-load. > > A perfect example of this problem is that most #hash URLs (as far as > scrolling) are broken on gist.github and github when viewed in recent > Firefox. > > https://gist.github.com/getify/5558974 > > I am proposing that the browser throw a JS event right before it's about > to try an auto-scroll to an element with the #id of the #hash in the URL > (during a page's initial loading), called for instance "autoscroll". The > purpose of this event is to simplify how a web app can detect and respond > to a URL having a #hash on it that would normally create a scrolling > behavior, even if the element isn't yet rendered for the window to scroll > to. That gist shows how you could listen for the event, and store for later > use which target-ID was going to be scrolled to, and manually scroll to it > at a later time. > > If you have an app that does client-side rendering where it can break > auto-scrolling, but you want it to work properly, you can of course > manually inspect the URL for a #hash at any point, but it's a bit awkward, > especially if you are already relying entirely on event-driven architecture > in the app, and you want to just detect and respond to events. This > "autoscroll" event will normalize that handling. > > Notice the polyfill code in the above gist shows that you can obviously > detect it yourself, but it's awkward, and would be nice if it were just > built-in. > > Additionally, having it be a built-in event would allow an app to prevent > the browser from doing unwanted auto-scrolling in a very simple and natural > way, by just trapping the event and calling `preventDefault()`. Currently, > there's not really a clean way to accomplish that, if you needed to. > > > > --Kyle > > >
Re: [whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)
Simon emailed me personally to answer my last question about what's next: "We
wait for the editor to process this thread. It might take a while, but
he'll get to it."
Other than that, there haven't been any discussions that I've been privy to.
Sincerely,
James Greene
On Tue, Aug 7, 2012 at 12:52 PM, Scott González wrote:
> Has there been any more discussion outside of this thread?
>
>
> On Fri, May 11, 2012 at 1:53 PM, James Greene wrote:
>
>> Alright... so what's next? I'm assuming this needs further discussion
>> with
>> other WHATWG members chiming in. If I can help, please let me know. I'd
>> like to see this request through.
>>
>> Sincerely,
>> James Greene
>>
>>
>>
>>
>> On Fri, May 11, 2012 at 12:26 PM, Simon Pieters wrote:
>>
>> > On Fri, 11 May 2012 17:14:00 +0200, James Greene <
>> james.m.gre...@gmail.com>
>> > wrote:
>> >
>> > Simon:
>> >> Yeah, I misunderstood your previous mention of having it as a [fifth]
>> >> string argument. I somehow associated that automatically with the
>> >> "message" parameter (the only string argument, I suppose) but I also
>> >> noticed my mistake after I sent the email.
>> >>
>> >
>> > OK.
>> >
>> >
>> > I personally am interested in adding the stack trace, yes,
>> >>
>> >
>> > OK, thanks.
>> >
>> >
>> > but ideally I
>> >> would just have access to the full "Error" object so I can always have
>> an
>> >> up-to-date model if the "Error" object continues to change (as it
>> probably
>> >> will).
>> >>
>> >
>> > That's fair enough. Though not all exceptions are Errors -- DOMException
>> > currently isn't, though I think some people want it to somehow inherit
>> from
>> > Error.
>> >
>> >
>> > For example, some devs may be interested in the "Error" object's
>> >> "name" property, which is already a part of the object today but is not
>> >> provided to "window.onerror" callbacks. And again, if additional
>> >> properties are added in the future, it's just more and more properties
>> >> that
>> >> may need to get incrementally added to the "window.onerror" invocation
>> >> arguments list. For example, I proposed the addition of an
>> "innerError"
>> >> property (or some would call it "cause") for chaining errors and
>> masking
>> >> internal errors that consumers shouldn't see, instead providing a
>> >> customer-facing message.
>> >>
>> >
>> > Yeah.
>> >
>> >
>> > You keep mentioning compile errors and how they don't have associated
>> >> "Error" objects but it sounds like they still reach the
>> "window.onerror"
>> >> callbacks. Can you add a little commentary on that?
>> >>
>> >
>> > Here are some examples:
>> >
>> > onerror = function(a,b,c) { alert(a+b+c) };
>> > foo();
>> > for (;)
>> > setTimeout('for (;)', 0);
>> >
>> >
>> >
>> >
>> > I thought they
>> >> utilized the "SyntaxError" class but perhaps that's only for "eval()"
>> >> calls...?
>> >>
>> >
>> > Yes. Since the script doesn't compile, the same script can't catch any
>> > exception in a try/catch block. onerror is just invoked with the
>> > appropriate arguments, and currently doesn't expose any object. Hence,
>> > compile errors currently do not expose any exception that Web pages can
>> > observe. However, if we change onerror and expose the exception object
>> for
>> > uncaught exceptions, it would certainly make sense to specify that
>> compile
>> > errors be exposed using SyntaxError exceptions.
>> >
>> > If we expose the exception object in onerror (which I actually think
>> makes
>> > sense), what do we want to happen for cross-origin script errors? null?
>> The
>> > current arguments are masked as ("Script error.", "", 0, 0).
>> >
>> >
>> > I may also be thinking of this differently as a JS engineer
>> >> versus a browser vendor, so please help clue me in. I'm interested to
>> >> learn more on this, and it may help me better appreciate why the
>> >> "window.onerror" callback mechanism *didn't* just pass an "Error"
>> object
>> >> from the beginning.
>> >>
>> >
>> > I think onerror is an old feature dating back from old Netscape or IE
>> > (don't know which). Then other browsers just copied it.
>> >
>> >
>> > I appreciate your continued feedback. Thanks!
>> >>
>> >
>> > cheers
>> >
>> > --
>> > Simon Pieters
>> > Opera Software
>> >
>>
>
>
Re: [whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)
Alright... so what's next? I'm assuming this needs further discussion with
other WHATWG members chiming in. If I can help, please let me know. I'd
like to see this request through.
Sincerely,
James Greene
On Fri, May 11, 2012 at 12:26 PM, Simon Pieters wrote:
> On Fri, 11 May 2012 17:14:00 +0200, James Greene
> wrote:
>
> Simon:
>> Yeah, I misunderstood your previous mention of having it as a [fifth]
>> string argument. I somehow associated that automatically with the
>> "message" parameter (the only string argument, I suppose) but I also
>> noticed my mistake after I sent the email.
>>
>
> OK.
>
>
> I personally am interested in adding the stack trace, yes,
>>
>
> OK, thanks.
>
>
> but ideally I
>> would just have access to the full "Error" object so I can always have an
>> up-to-date model if the "Error" object continues to change (as it probably
>> will).
>>
>
> That's fair enough. Though not all exceptions are Errors -- DOMException
> currently isn't, though I think some people want it to somehow inherit from
> Error.
>
>
> For example, some devs may be interested in the "Error" object's
>> "name" property, which is already a part of the object today but is not
>> provided to "window.onerror" callbacks. And again, if additional
>> properties are added in the future, it's just more and more properties
>> that
>> may need to get incrementally added to the "window.onerror" invocation
>> arguments list. For example, I proposed the addition of an "innerError"
>> property (or some would call it "cause") for chaining errors and masking
>> internal errors that consumers shouldn't see, instead providing a
>> customer-facing message.
>>
>
> Yeah.
>
>
> You keep mentioning compile errors and how they don't have associated
>> "Error" objects but it sounds like they still reach the "window.onerror"
>> callbacks. Can you add a little commentary on that?
>>
>
> Here are some examples:
>
> onerror = function(a,b,c) { alert(a+b+c) };
> foo();
> for (;)
> setTimeout('for (;)', 0);
>
>
>
>
> I thought they
>> utilized the "SyntaxError" class but perhaps that's only for "eval()"
>> calls...?
>>
>
> Yes. Since the script doesn't compile, the same script can't catch any
> exception in a try/catch block. onerror is just invoked with the
> appropriate arguments, and currently doesn't expose any object. Hence,
> compile errors currently do not expose any exception that Web pages can
> observe. However, if we change onerror and expose the exception object for
> uncaught exceptions, it would certainly make sense to specify that compile
> errors be exposed using SyntaxError exceptions.
>
> If we expose the exception object in onerror (which I actually think makes
> sense), what do we want to happen for cross-origin script errors? null? The
> current arguments are masked as ("Script error.", "", 0, 0).
>
>
> I may also be thinking of this differently as a JS engineer
>> versus a browser vendor, so please help clue me in. I'm interested to
>> learn more on this, and it may help me better appreciate why the
>> "window.onerror" callback mechanism *didn't* just pass an "Error" object
>> from the beginning.
>>
>
> I think onerror is an old feature dating back from old Netscape or IE
> (don't know which). Then other browsers just copied it.
>
>
> I appreciate your continued feedback. Thanks!
>>
>
> cheers
>
> --
> Simon Pieters
> Opera Software
>
Re: [whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)
Simon:
Yeah, I misunderstood your previous mention of having it as a [fifth]
string argument. I somehow associated that automatically with the
"message" parameter (the only string argument, I suppose) but I also
noticed my mistake after I sent the email.
I personally am interested in adding the stack trace, yes, but ideally I
would just have access to the full "Error" object so I can always have an
up-to-date model if the "Error" object continues to change (as it probably
will). For example, some devs may be interested in the "Error" object's
"name" property, which is already a part of the object today but is not
provided to "window.onerror" callbacks. And again, if additional
properties are added in the future, it's just more and more properties that
may need to get incrementally added to the "window.onerror" invocation
arguments list. For example, I proposed the addition of an "innerError"
property (or some would call it "cause") for chaining errors and masking
internal errors that consumers shouldn't see, instead providing a
customer-facing message.
You keep mentioning compile errors and how they don't have associated
"Error" objects but it sounds like they still reach the "window.onerror"
callbacks. Can you add a little commentary on that? I thought they
utilized the "SyntaxError" class but perhaps that's only for "eval()"
calls...? I may also be thinking of this differently as a JS engineer
versus a browser vendor, so please help clue me in. I'm interested to
learn more on this, and it may help me better appreciate why the
"window.onerror" callback mechanism *didn't* just pass an "Error" object
from the beginning.
I appreciate your continued feedback. Thanks!
Sincerely,
James Greene
On Fri, May 11, 2012 at 12:42 AM, Simon Pieters wrote:
> On Thu, 10 May 2012 21:14:23 +0200, James Greene
> wrote:
>
> In my opinion, adding the stack trace to the existing message would be
>> messy, breaks existing developer expectations, and possibly even breaks
>> backward compatibility of specific libraries/functions/**monitoring/etc.
>> in
>> some more extreme situations. If we can't just have the "Error" object
>> itself passed in, I'd much prefer "stack" as a fifth parameter versus
>> unexpected modification of an existing parameter.
>>
>
> Right, "stack" as a fifth parameter was what I suggested.
>
>
> We can also keep adding parameters to the "window.onerror" invocation till
>> we're blue in the face...
>>
>
> Or only add parameters that solve use cases being presented...
>
>
> but, in reality, don't we just want all of the
>> properties of the relevant "Error" object?
>>
>
> I don't know, that why I asked what you want.
>
> I'd really love to *just* have
>>
>> the "Error" object passed (e.g. "window.onerror(function(e) { ... })") but
>> I know that would break backward compatibility, so I didn't propose it.
>>
>
> What do you want for compile errors, which don't have an Error object at
> all?
>
> It seems to me like "columnNumber" should be added to the "Error" object
>> as
>> a standard (speaking of which: https://github.com/JSFixed/**
>> JSFixed/issues/51 <https://github.com/JSFixed/JSFixed/issues/51>)
>> *instead of* adding it as yet another parameter to the already ugly
>>
>> "window.onerror", and then just pass the "Error" object so devs can get
>> whatever information they want from it.
>>
>
> What about compile error?
>
>
> But, if it's a security thing, I
>> guess I'm willing to accept that
>>
>
> The security thing is solvable either way.
>
>
> --
> Simon Pieters
> Opera Software
>
Re: [whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)
In my opinion, adding the stack trace to the existing message would be
messy, breaks existing developer expectations, and possibly even breaks
backward compatibility of specific libraries/functions/monitoring/etc. in
some more extreme situations. If we can't just have the "Error" object
itself passed in, I'd much prefer "stack" as a fifth parameter versus
unexpected modification of an existing parameter.
We can also keep adding parameters to the "window.onerror" invocation till
we're blue in the face... but, in reality, don't we just want all of the
properties of the relevant "Error" object? I'd really love to *just* have
the "Error" object passed (e.g. "window.onerror(function(e) { ... })") but
I know that would break backward compatibility, so I didn't propose it.
It seems to me like "columnNumber" should be added to the "Error" object as
a standard (speaking of which: https://github.com/JSFixed/JSFixed/issues/51)
*instead of* adding it as yet another parameter to the already ugly
"window.onerror", and then just pass the "Error" object so devs can get
whatever information they want from it. But, if it's a security thing, I
guess I'm willing to accept that....
Sincerely,
James Greene
On Wed, May 9, 2012 at 4:12 AM, Simon Pieters wrote:
> On Wed, 09 May 2012 03:56:29 +0200, James Greene
> wrote:
>
> Full proposal details:
>>
>> https://gist.github.com/**3ded0f6e7f0a658b9394<https://gist.github.com/3ded0f6e7f0a658b9394>
>>
>
> quoting the above (revision https://gist.github.com/**
> 3ded0f6e7f0a658b9394/**51e980f0474c255738a3b6ecf003bb**6cb30db49c<https://gist.github.com/3ded0f6e7f0a658b9394/51e980f0474c255738a3b6ecf003bb6cb30db49c>):
>
> # Proposal: Add `window.getLastError` (or modify `window.onerror`)
>> ## Error handling in an isolated scope
>> In our applications, most of us hopefully follow the UX best practice of
>> catching unexpected and/or unpreventable errors and logging them back to
>> the server-side for monitoring.
>> In isolated scopes, this can be achieved by setting up a try-catch block,
>> which also allows you to inspect the pertinent [`Error`][1] object itself:
>> ```
>> try {
>>throw new Error("WTF");
>> } catch (e) {
>>alert("Isolated error! Details: " + e);
>> }
>> ```
>> This is very useful, especially in browsers that support the [`stack`][2]
>> property of the `Error` object to improve "debugability". This property's
>> availability is also of great benefit to @eriwen's [StackTrace.js][3],
>> which I find to be handy (though I'm not a big fan of the StrackTrace.js
>> API, as @eriwen and I have discussed previously).
>> ## Error handling at the global scope
>> Setting up layers of try-catch blocks quickly becomes unreasonable in
>> large applications. As an alternative, we can attach a listener to the
>> [`window`][4] object's [`error`][5] event, which is invoked whenever an
>> error bubbles up without being handled elsewhere:
>>
>
> (It's not actually a real event.)
>
> ```
>> var oldOnError = window.onerror;
>> window.onerror = function myErrorHandler(errorMsg, url, lineNumber) {
>>if (oldOnError) {
>>return oldOnError(errorMsg, url, lineNumber);
>>}
>> alert("Globally unhandled error! Details: " + errorMsg);
>>return false;
>> }
>> ```
>> ## The problem with `window.onerror`
>> The problem is that this mechanism does not allow us to inspect the
>> pertinent `Error` object at all: it only provides us with three arguments
>> at invocation time: message (string), fileName (string), and lineNumber
>> (number). These are rarely useful in practice.
>>
>
> The spec now has a fourth argument for the column number (which is more
> useful than line number for minimized scripts). Maybe column could be made
> available on exceptions as well, though that's up to TC39, I think.
> ('stack' isn't specified currently, IIRC.)
>
> ## My proposal(s) to fix it
>> As such, I propose the following two options as fixes:
>> 1. Add a function like `getLastError` to the global `window` object that
>> would fetch the actual `Error` object associated with the most recent
>> unhandled error. I would foresee common usage looking something like the
>> following:
>> ```
>> var oldOnError = window.onerror;
>> window.onerror = function myErrorHandler(errorMsg, url, lineNumber) {
>>if (oldOnError) {
>>return oldOnError(errorMsg, url, li
[whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)
Full proposal details: https://gist.github.com/3ded0f6e7f0a658b9394 P.S. I had no idea what "product" to file this under in the W3C Bugzilla, so it has NOT been filed there. I HAVE posted a new topic to the Forums but it is still awaiting moderator approval. Sincerely, James Greene
