This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25224 - More detail for abort event
Summary: More detail for abort event
Status: RESOLVED WORKSFORME
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-01 23:27 UTC by Arkadiusz Michalski (Spirit)
Modified: 2014-07-28 21:50 UTC (History)
2 users (show)

See Also:


Attachments

Description Arkadiusz Michalski (Spirit) 2014-04-01 23:27:53 UTC
When this event should be exactly fired? 

Algo aborted: http://www.w3.org/html/wg/drafts/html/master/browsers.html#abort-a-document

I see comment for this in source spec:
<!-- I'd love to make this more precise, anyone have any suggestions on what it should say? -->

Bellow algo we have this:
[User agents may allow users to explicitly invoke the abort a document algorithm for a Document. If the user does so, then, if that Document is an active document, the user agent should queue a task to fire a simple event named abort at that Document's Window object before invoking the abort algorithm.]

What means "explicity"? From JS code, manual, or both? From JS (according to html) only window.close() do this. 

And this event is fired for multimedia elements too :http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#fatal-decode-error(check next dd element because we dont have id for this << step 3.)
Table for events should include Element (now show only Window): http://www.w3.org/html/wg/drafts/html/master/index.html#event-abort

Algo aborted apper on other algo like:
navigated (http://www.w3.org/html/wg/drafts/html/master/browsers.html#navigate)
discard (http://www.w3.org/html/wg/drafts/html/master/browsers.html#discard-a-document)
But don't know whether they are treated as "explicity". User can manual navigate to other place or close document (or programatically). << all this case should fired abort event?

BTW, in IE press "escape" button fired this event too. This is/should be standard behavior? What if we stop load page when press X icon in browser tooolbar, should fire abort event? 

In other browser it's seems this event not implemented yet or I don't know how to fire them so I asked so many questions.
Comment 1 Ian 'Hixie' Hickson 2014-05-06 23:00:59 UTC
Note that the spec you reference is a fork. The original and canonical spec is:

   http://whatwg.org/html


> What means "explicity"? From JS code, manual, or both?

Users can't run JS code, so it has to be manually. "Explicitly" means that they're clearly making the request to run this algorithm specifically, as opposed to implicitly invoking it by doing something that triggers another algorithm that invokes this one or one like it.


> << all this case should fired abort event?

I'm not sure what you are asking here. The 'abort' event is fired whenever the spec says to fire it.


> BTW, in IE press "escape" button fired this event too.

That's an explicit request to abort, as mentioned in the spec.


Please file a single bug per issue. I'm not really sure what spec changes are needed to address the issues in this bug. Can you clarify what change you are looking for?
Comment 2 Arkadiusz Michalski (Spirit) 2014-05-07 01:01:51 UTC
Let's say that in this case I bother you unnecessarily (but thx for some explanation).

To some benefit from the opening this bug I suggest just add to abort event targets:

http://www.whatwg.org/specs/web-apps/current-work/#event-abort

media element (audio and video); because it would fit.

And maybe add some id="" for click event in this table, now we can't refer exactly to this place (where we see possible targets and description for this event).
Comment 3 Ian 'Hixie' Hickson 2014-07-23 19:39:35 UTC
All hyperlinks and definitions have IDs now.

The table for media events is at:
   http://www.whatwg.org/specs/web-apps/current-work/#mediaevents

I don't really want to have to update the main event index every time the media event stuff changes, which is why they're not merged currently.

Does that make sense?
Comment 4 Arkadiusz Michalski (Spirit) 2014-07-23 23:30:07 UTC
(In reply to Ian 'Hixie' Hickson from comment #3)
> Does that make sense?

Sure, now I see that below main event index we have some information:

[See also media element events, application cache events, and drag-and-drop events.]

It is sufficient, you can close this bug.
Comment 5 Ian 'Hixie' Hickson 2014-07-28 21:50:56 UTC
Great, thanks for following up!

Please don't hesitate to file other bugs or reopen this one if you change your mind.