Tracking Issue: WhatWG issues opened by or tracked by Ladybird

[ADKaster]

Open Spec issues:

whatwg/html:

• Removal of implied document Attempt to remove implied-document definition whatwg/html#4980
  Algorithm: HostEnqueuePromiseJob
  See:

  ladybird/Userland/Libraries/LibWeb/Bindings/MainThreadVM.cpp

  Lines 267 to 270 in 01ff3d4

  	// 2. Queue a microtask on the surrounding agent's event loop to perform the following steps:
  	// This instance of "queue a microtask" uses the "implied document". The best fit for "implied document" here is "If the task is being queued by or for a script, then return the script's settings object's responsible document."
  	// Do note that "implied document" from the spec is handwavy and the spec authors are trying to get rid of it: https://github.com/whatwg/html/issues/4980
  	auto* script = active_script();

• UA style for <br> and <wbr> UA style for <br> and <wbr> whatwg/html#2291
  Algorithm: https://html.spec.whatwg.org/multipage/rendering.html#phrasing-content-3
  See:

  ladybird/Userland/Libraries/LibWeb/CSS/Default.css

  Lines 366 to 371 in 01ff3d4

  	/*
  	NOTE: This isn't a real property and value. See https://github.com/whatwg/html/issues/2291
  	br {
  	display-outside: newline;
  	}
  	*/

  
  

  ladybird/Userland/Libraries/LibWeb/CSS/StyleComputer.cpp

  Lines 2352 to 2356 in 01ff3d4

  	// NOTE: We never blockify <br> elements. They are always inline.
  	// There is currently no way to express in CSS how a <br> element really behaves.
  	// Spec issue: https://github.com/whatwg/html/issues/2291
  	if (is<HTML::HTMLBRElement>(element))
  	return BoxTypeTransformation::None;

• Aborting document load impact on descendant navigables aborting a document load does not abort ongoing navigation of descendant navigables whatwg/html#9711
  Algorithm: abort a document and its descendants
  See:

  ladybird/Userland/Libraries/LibWeb/DOM/Document.cpp

  Lines 3323 to 3328 in 01ff3d4

  	// 3. For each descendantNavigable of descendantNavigables, queue a global task on the navigation and traversal task source given descendantNavigable's active window to perform the following steps:
  	for (auto& descendant_navigable : descendant_navigables) {
  	HTML::queue_global_task(HTML::Task::Source::NavigationAndTraversal, *descendant_navigable->active_window(), JS::create_heap_function(heap(), [this, descendant_navigable = descendant_navigable.ptr()] {
  	// NOTE: This is not in the spec but we need to abort ongoing navigations in all descendant navigables.
  	// See https://github.com/whatwg/html/issues/9711
  	descendant_navigable->set_ongoing_navigation({});

whatwg/console

• Warn if timer doesn't exist when logging time Timing and Counting methods should report warnings when necessary whatwg/console#134
  Algorithm: timeLog https://console.spec.whatwg.org/#timelog
  See:

  ladybird/Userland/Libraries/LibJS/Console.cpp

  Lines 394 to 403 in 01ff3d4

  	// NOTE: Warn if the timer doesn't exist. Not part of the spec yet, but discussed here: https://github.com/whatwg/console/issues/134
  	if (maybe_start_time == m_timer_table.end()) {
  	if (m_client) {
  	MarkedVector<Value> timer_does_not_exist_warning_message_as_vector { vm.heap() };
  	auto message = TRY_OR_THROW_OOM(vm, String::formatted("Timer '{}' does not exist.", label));
  	timer_does_not_exist_warning_message_as_vector.append(PrimitiveString::create(vm, move(message)));
  	TRY(m_client->printer(LogLevel::Warn, move(timer_does_not_exist_warning_message_as_vector)));
  	}

---

Resolved Spec issues:

whatwg/html

• Document destruction in navigables Overhaul document unloading/destruction/aborting whatwg/html#9907
  Algorithm: destroy a document https://html.spec.whatwg.org/multipage/document-lifecycle.html#destroy-a-document
  See:

  ladybird/Userland/Libraries/LibWeb/DOM/Document.cpp

  Lines 3210 to 3212 in 01ff3d4

  	// NOTE: Abort needs to happen before destory. There is currently bug in the spec: https://github.com/whatwg/html/issues/9148
  	// 4. Abort document.
  	abort();

  
  Resolved in Ladybird: NO

[ADKaster]

@sideshowbarker This is what I was kind of thinking of for some sort of tracking list. Do you have any thoughts on how to organize/gather this information? This first cut was done with some manual git grep whatwg/html and link following.

[sideshowbarker]

@sideshowbarker This is what I was kind of thinking of for some sort of tracking list.

Thanks for putting it together

Do you have any thoughts on how to organize/gather this information?

As far as how to organize it, I think that looks great

This first cut was done with some manual git grep whatwg/html and link following.

So when I do that, I get a bigger list:

$ git grep "whatwg/html/issues"  \
    | perl -pe 's/^.+(https.+whatwg\/html\/issues\/[0-9]+).*$/\1/' | sort --version-sort | uniq
https://github.com/whatwg/html/issues/2291
https://github.com/whatwg/html/issues/3255
https://github.com/whatwg/html/issues/4792
https://github.com/whatwg/html/issues/4980
https://github.com/whatwg/html/issues/8534
https://github.com/whatwg/html/issues/9122
https://github.com/whatwg/html/issues/9148
https://github.com/whatwg/html/issues/9355
https://github.com/whatwg/html/issues/9690
https://github.com/whatwg/html/issues/9711
https://github.com/whatwg/html/issues/9767
https://github.com/whatwg/html/issues/9869
https://github.com/whatwg/html/issues/9923
https://github.com/whatwg/html/issues/9973
https://github.com/whatwg/html/issues/10019
https://github.com/whatwg/html/issues/10192
https://github.com/whatwg/html/issues/10232
https://github.com/whatwg/html/issues/10240
https://github.com/whatwg/html/issues/10261

But I guess you already went through that whole longer list, to filter it down to just the issues we want to take action on?

I addition to that, doing git grep -i "spec bug" seems to catch some that don’t have upstream issues raised yet —

$ git grep -i "spec bug" | rg -v "whatwg/[a-z]+/issues"
Userland/Libraries/LibJS/CyclicModule.cpp:    // NOTE: This is likely a spec bug, see https://matrixlogs.bakkot.com/WHATWG/2023-02-13#L1
Userland/Libraries/LibJS/CyclicModule.cpp:    // FIXME: This is likely a spec bug, see load_requested_modules.
Userland/Libraries/LibJS/Runtime/Temporal/Duration.cpp:        // FIXME: spec bug, this should be set.
Userland/Libraries/LibJS/Runtime/Temporal/Duration.cpp:        // FIXME: spec bug, should be set
Userland/Libraries/LibJS/Runtime/Temporal/TimeZone.cpp:                //     FIXME: spec bug? shouldn't [[EpochNanoseconds]] just be called [[Nanoseconds]]?
Userland/Libraries/LibWeb/Crypto/SubtleCrypto.cpp:    // FIXME: Spec bug: link to https://webidl.spec.whatwg.org/#a-promise-rejected-with
Userland/Libraries/LibWeb/DOM/Document.cpp:        // FIXME: Why do we assume `creation_url` is non-empty here? Is this a spec bug?
Userland/Libraries/LibWeb/DOM/Document.cpp:        // FIXME: Why do we assume `top_level_creation_url` is non-empty here? Is this a spec bug?
Userland/Libraries/LibWeb/DOM/DocumentLoading.cpp:    //        default to an "about:blank" url. Is this a spec bug?
Userland/Libraries/LibWeb/HTML/BrowsingContext.cpp:    // FIXME: There appears to be no way to get a null URL here, so it might be a spec bug.
Userland/Libraries/LibWeb/HTML/HTMLImageElement.cpp:            // FIXME: Spec bug! `selected_pixel_density` can be undefined here, per the spec.
Userland/Libraries/LibWeb/HTML/Parser/HTMLParser.cpp:                //        This might be a spec bug(?)
Userland/Libraries/LibWeb/Layout/FlexFormattingContext.cpp:        //       Spec bug: https://github.com/w3c/csswg-drafts/issues/2890

…(though I realize the first ones are maybe ES spec bugs)

…and that incidentally also shows: for catching WHATWG issues, I guess we need `git grep "whatwg/[a-z]+/issues" or such:

$ git grep "whatwg/[a-z]\+/issues" | rg -v "whatwg/html" \
    | perl -pe 's/^.+(https.+whatwg\/[a-z]+\/issues\/[0-9]+).*$/\1/' | sort --version-sort | uniq
https://github.com/whatwg/console/issues/134
https://github.com/whatwg/dom/issues/221
https://github.com/whatwg/dom/issues/907
https://github.com/whatwg/dom/issues/1102
https://github.com/whatwg/encoding/issues/312
https://github.com/whatwg/fetch/issues/1035

[ADKaster]

But I guess you already went through that whole longer list, to filter it down to just the issues we want to take action on?

On the contrary, I wrote down the details for the first 5 I found and then got bored, hoping that "there's surely a way to script this" :)

[sideshowbarker]

OK, if it seems like we have agreement on using the wiki for this, and you start a wiki page for this there — with a dump of the markdown for the subset already in the issue description — then, I can make time to add all the rest of the issues (following the format in the issue description).

[ADKaster]

I've transposed this data so far into a markdown file in #893. It feels... incomplete, and hard to work with, but still better than a github issue.

[AtkinsSJ]

If a single document is awkward, what about just making each individual one its own GitHub issue, with a shared label?

[sideshowbarker]

If a single document is awkward, what about just making each individual one its own GitHub issue, with a shared label?

I think that could work fine too. I plan on helping follow up on the related issues upstream, helping them get attention upstream (e.g., by being on the WHATNOT calls to discuss them), and I don’t have any strong opinions about how the project manages the tracking for them here.