Introduce Object.hasOwn

FYI This proposal has now reached Stage 3

https://github.com/tc39/proposals#stage-3
https://github.com/tc39/proposal-accessible-object-hasownproperty#status

I am waiting on the soft freeze period to finish, and will land after that.

https://hg.mozilla.org/mozilla-central/rev/9c839a537310

FYI the test262 tests have been merged: https://github.com/tc39/test262/pull/2995

Not sure if that was the reason for putting it behind a nightly flag or not

FYI FF91 docs on this can be tracked in https://github.com/mdn/content/issues/6717

This feature appears to be restricted to nightly only. My understanding is that normally we wouldn't call something "fixed" in a particular build until it is available in a release. So, is this going to be available in the release build of FFv91?

For TC39 features, we sometimes split into two parts, one implementation bug and one shipping bug. This allows us to test the feature at stage 3 until we are sure that it is ready, as there may be web compatibility issues that crop up in nightly. This corresponds with sending an "Intent to Prototype" email to the mailing list. Once the testing is finished, we merge a "ship" bug and send an "intent to ship".

If the question is rather "when" will it ship, we have had it in nightly for a month now and there haven't been issues, so I will probably do it next week. This typically depends on the feature, sometimes we don't unflag until they go to stage 4 or are about to -- for others if we are certain we might ship right away.

My understanding is that we won't be promoting it to Stage 4 until it lands in at least two browsers unflagged. But I think this feedback should meet the other requirement of significant feedback in the field so maybe we can move forward with that.

With regards to the process document -- the process document does not require two unflagged implementations as significant in the field experience (though you may say it is recommended as the example provided for significant in the field experience is unflagged implementations). Significant in the field experience is not the same thing as unflagging the implementation however. Two implementations ensure multi-implementer buy in and is an important part of the process. An example is top level await -- only chrome had it fully unflagged, firefox shipped unflagged only as it was going to stage 4 (not before). Significant in the field experience was achieved via Node and transpilers. One risk is that this might end up not being so smooth: spec adjustments were made after chrome shipped and had to be approved and landed quickly as a resultl.

For some proposals, the champion may wish to have more confidence before moving forward, and may wait for a high confidence signal from more browsers. I think this is a better signal, and would recommend to wait until there are two browsers shipping unflagged or have plans to do so.

The only browser to use unflagging as a policy is chrome -- they do not consider it to be significant in the field experience without unflagging. Not all browsers follow this however. Two browsers shipping unflagged means that they both believe that the proposal will not change any further, as unflagging may ultimately change the landscape for the feature. I took a more cautious approach in particular because we recently had problems with the .at proposal, which also added a builtin method and first shipped in nightly. It ultimately required one rename, and negotiation with a site to change their code after that rename. This web compat issue was identified in nightly.

@Yulia Thanks very much.

• So how can I, as a documentation author, tell whether something has shipped or not? Is there a field here or is it that if I don't see the words shipping somewhere in the title?
• Do you think this will actually ship in FF91? (not just nightly)?

[Or to put it another way, I assumed this was released, because I was handed this docs task https://github.com/mdn/content/issues/6717. I want to make sure that the docs process for finding release items is robust so I don't waste engineer time]

We can make this process clearer -- often we haven't been linking the "ship" bug to the "implement" bug so they are hard to discover. For now, you should look for a ship bug to determine when it is shipped unflagged. This might still be a bit tricky, for proposals that are small or that add options to an api such as https://bugzilla.mozilla.org/show_bug.cgi?id=1693575, we do not have a shipping bug (for example also, error cause appears to be shipping without being flagged). They ship automatically. Perhaps it won't be much of an issue. Otherwise, we have our "intent to ship" email which goes out on firefox-dev mailing list. Open to other suggestions as well. If you are unsure at any point, you can ping me on matrix -- this isn't a problem at all.

As for if this ships in 91: no, we are already past that deadline (2021-07-12). This will ship in 92.

Thank you for explaining that to me, I'm new to all of this so I greatly appreciate it.

If it helps:

• I intend to ask for Stage 4 at the next TC39 meeting, Chrome has already said they will be shipping it by then, and I've been encouraged to move to Stage 4 by people with more experience.
• There has not been any new or unaddressed feedback since the review of the spec in Stage 2. Only some clarifying questions from users.
• I think the only remaining question is if it breaks anything already on the web, which yall are in a better position to answer, but nothing has been noted so far.

Thanks @yulia

Re https://bugzilla.mozilla.org/show_bug.cgi?id=1711872#c12 and tracking shipping/docs, I will ask Ruth to have a look at this as she's currently running the process and might already have this in hand.

That said, my 2 bits:

• I "believe" that docs process is simply to look for bugs that have dev-docs-needed and/or that have the appropriate release tagged in the tracking section.
• IMO it should be clear from a bug report which releases any fix ships to.
• I would love tag(s) in the tracking section that perhaps let me know
  • shipped (in a release build) or not.
  • if not shipped, in which releases - nightly, beta, etc?
  • intent to ship target release (if not released). Just an "guess" is fine for planning, not a committment.
  • if protected by a preference or not, and ideally what that is.
• Further, it would also save a lot of time if authors summarised what delivered, in particular if it differs in any way from the description. That is not relevant to this particular issue which has a really excellent spec. Often though there is a large chain of discussion and evolution for bug fixes, and what finally delivered is pretty unclear.

Hope that makes sense.

I don't know if you are already familiar, but much of that information is sent in the intent to prototype emails which I mentioned earlier. For example for this bug. I will detail the "intent" process later.

Your comment however suggests that there might be more misunderstandings and this is more pressing. You indicated that you expect the implementation bug to include the feature documentation itself. This is not the case, we do not design the features: The information you are looking for when you ask "what feature does this implement and how does it work?" is the linked proposal repository, not in the bug. The proposal is always linked. All stage 3 proposals are expected to have a detailed explainer of what the feature is, why it is being developed, and what it does.

This is really critical: When documenting a new feature for the web as designed by TC39, always go to the proposal, that is why it is linked Do not rely on the implementation bug. The details discussed around implementation are not relevant for this and are likely to be confusing.

Along the lines of this specification/implementation split: It seems that your process has changed since I was working with the docs team in the past and I am happy to adapt. I created this bug as a clone of past bugs, because before, if the dev-docs-needed wasn't there -- someone from the doc team has come and added that label to any tc39 feature that was being added. That was usually before implementation had started. For example, the dev-doc-needed here was added 2 years prior to the feature being implemented -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#a74075_374863. The documentation was completed before the feature shipped -> https://bugzilla.mozilla.org/show_bug.cgi?id=1519100#c33 . This documentation was browser agnostic. The firefox status was updated as part of a separate bug dedicated to shipping the proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=1681046#c17 as is part of our implement then ship split on many bugs.

I will leave it to you and your team to decide how you want to go forward, if you want a new label or not to distinguish between these two cases, if you want to eagerly document and then update the firefox status or not. We are not required to implement everything right away, so from a user perspective, a split between "the feature has been specified" and "firefox has implemented" is a useful one, as sometimes we implement a year or more later. I understood your process to be to eagerly document regardless of our implementation status. That said, the exposure guidelines are browser wide and is established process. For now, I will stop adding dev-doc-needed to new TC39 feature bugs and leave that to you and your team, as this seems to have sparked some confusion. Once you have a process you are happy with, you can let me know how I can help and I am happy to follow those guidelines in relation to the use of the labels.

Otherwise, for identifying when something shipped when it is not directly clear: This is where "intents" come into play. I already shared the intent to prototype for this bug. Following or searching the dev-platform mailing list (though it isn't always perfect) is likely easier than going through the bug discussions. If you are working on documentation for multiple browsers, here is an example from chrome bug and here is their intent to ship.

There are two tiers: intent to prototype, and intent to ship. They can be combined. Which one to send and when is at the discretion of the person writing it. From my perspective, because stage 3 proposals in TC39 are intended to be prototyped and tested (as signified by stage 3 acceptance in the process), I usually implement them and send an intent to prototype for the duration of the time that it is flagged or nightly-only, unless we ship by default for small changes. Intent to ship is sent with information about when it is enabled by default. Full documentation is here -- this applies to all new features in the browser, not only TC39 features. Given that other standards have their own process, the main thing that lines up is the intent to ship -- which is also what you are interested in.

Since you are relying on the bugs for this information I think part of the problem lies in information discovery. This should also clarify when something has shipped. I think what may be a good way forward is to copy that email, or link it, into the bug body. That way you can have that information in the bug as well and can quickly search for the information. Adding process means communicating to a lot of people what the new process is, and since exposure guidelines already exist I think it is better to use those. I would rather strengthen our existing process than to add new, component specific, processes. If something is missing in the mailing lists, you can fall back onto the bug or ask. I think in most cases it will be straight forward. It would also motivate us to send those emails, which we don't always do. The emails have a broader reach than the bug alone.

To answer the question of "when" something will ship while it is in the prototype phase, it is often very hard to say and would be inappropriate in some cases.