Consider this testcase:

<iframe src="javascript:true" onload="alert('event fired')"></iframe>

Until recently, this fired the load even in all browsers. When Firefox changed to not firing the load event here (following the current spec), we encountered breakage in websites: there are sites that run javascript: URLs that return booleans in frames and wait for the load event before doing something else [1]. Note that Firefox never fired a load event in this situation for the "javascript:undefined" case, but other browsers do.

The current state of this in the spec is as follows:

1. Start at https://html.spec.whatwg.org/multipage/embedded-content.html#process-the-iframe-attributes
2. No srcdoc attr, have an src attr, so go to https://html.spec.whatwg.org/multipage/embedded-content.html#otherwise-steps-for-iframe-or-frame-elements
3. Step 4 lands in https://html.spec.whatwg.org/multipage/browsers.html#navigate
4. We enter the parallel section of navigation.
5. The request's url's scheme is "javascript", so we queue a task to run https://html.spec.whatwg.org/multipage/browsers.html#javascript-protocol
6. In step 11 the response is set to a 204 response, since the return value is not a String.
7. In step 12 we go to https://html.spec.whatwg.org/multipage/browsers.html#process-a-navigate-response
8. In step 2 the steps are aborted.

I don't see anything in the spec right now that would fire a load event in this situation. There presumably needs to be something.

Of course not-initial javascript: loads that return a boolean shouldn't fire a load event (or should it? I haven't tested non-Firefox browsers here), which adds to the fun of the whole thing.

[1] For example, the jQuery fileupload library does this. See https://bugzilla.mozilla.org/show_bug.cgi?id=1307420#c9 but chances are all the duplicates of https://bugzilla.mozilla.org/show_bug.cgi?id=1306472 will have similar issues on their sites.