Skip to content

Commit 8a9f82e

Browse files
gnoffgnoff
authored
[Float][Fizz][Fiber] - Do not hoist elements with itemProp & hydrate more tolerantly in hoist contexts (#26256)
## Do not hoist elements with `itemProp` In HTML `itemprop` signifies a property of an `itemscope` with respect to the Microdata spec (https://html.spec.whatwg.org/multipage/microdata.html#microdata) additionally `itemprop` is valid on any tag and can even make some tags that are otherwise invalid in the `<body>` valid there (`<meta>` for instance). Originally I tried an approach where if you rendered something otherwise hoistable inside an `itemscope` it would not hoist if it had an `itemprop`. This meant that some components with `itemprop` could hoist (if they were not scoped, which is generally invalid microdata implementation). However the problem is things that do hoist, hoist into the head and body and these tags can have an `itemscope`. This creates a ton of ambiguity when trying to hydrate in these hoist scopes because we can't know for certain whether a DOM node we find there was hoisted or not even if it has an `itemprop` attribute. There are other scenarios too that have abiguous semantics like rendering a hoistable with `itemProp` outside of `<html itemScope={true>`. Is it fair to embed that hoistable inside that itemScope even though it was defined outside? To simplify the situation and disambiguate I dropped the `itemscope` portion from the implementation and now any host component that could normally be hoisted will not hoist if it has an `itemProp` prop. In addition to the changes made for `itemProp` this PR also modifies part of the hydration implementation to be more tolerant of tags injected by 3rd parties. This was opportunistically done when we needed to have context information like `inItemScope` but with the most recent implementation that has been removed. I have however left the hydration changes in place as it is a goal to make React handle hydrating the entire Document even when we cannot control whether 3rd parties are going to inject tags that React will not render but are also not hoistables ------- ##### Original Description when we considered tracking itemScope >One recent decision was to make elements using the `itemProp` prop not hoistable if they were inside and itemScope. This better fits with Microdata spec which allows for meta tags and other tag types usually reserved for the `<head>` to be used in the `<body>` when using itemScope. > >To implement this a number of small changes were necessary > >1. HostContext in prod needed to expand beyond just tracking the element namespace for new element creation. It now tracks whether we are in an itemScope. To keep this efficient it is modeled as a bitmask. >2. To disambiguate what is and is not a potential instance in the DOM for hoistables the hydration algo was updated to skip past non-matching instances while attempting to claim the instance rather than ahead of time (getNextHydratable). >3. React will not consider an itemScope on `<html>`, `<head>`, or `<body>` as a valid scope for the hoisting opt-out. This is important as an invariant so we can make assumptions about certain tags in these scopes. This should not be a functional breaking change because if any of these tags have an `itemScope` then it can just be moved into the first node inside the `<body>` > >Since we were already updating the logic for hydration to better support `itemScope` opt-out I also changed the hydration behavior for suspected 3rd party nodes in `<head>` and `<body>`. Now if you are hydrating in either of those contexts hydration will skip past any non-matching nodes until it finds a match. This allows 3rd party scripts and extensions to inject nodes in either context that React does not expect and still avoid a hydration mismatch. > >This new algorithm isn't perfect and it is possible for a mismatch to occur. The most glaring case may be if a 3rd party script prepends a `<div>` into `<body>` and you render a `<div>` in `<body>` in your app. there is nothing to signal to React that this div was 3rd party so it will claim is as the hydrated instance and hydration will almost certainly fail immediately afterwards. > >The expectation is that this is rare and that if falling back to client rendering is transparent to the user then there is not problem here. We will continue to evaluate this and may change the hydration matching algorithm further to match user and developer expectations
1 parent 3cad3a5 commit 8a9f82e

12 files changed

+983
-398
lines changed

‎packages/react-dom-bindings/src/client/ReactDOMComponent.js

+94-89
Original file line numberDiff line numberDiff line change
@@ -55,7 +55,12 @@ import {
5555
setValueForStyles,
5656
validateShorthandPropertyCollisionInDev,
5757
} from './CSSPropertyOperations';
58-
import {HTML_NAMESPACE, getIntrinsicNamespace} from '../shared/DOMNamespaces';
58+
import {
59+
HTML_NAMESPACE,
60+
MATH_NAMESPACE,
61+
SVG_NAMESPACE,
62+
getIntrinsicNamespace,
63+
} from '../shared/DOMNamespaces';
5964
import {
6065
getPropertyInfo,
6166
shouldIgnoreAttribute,
@@ -375,112 +380,112 @@ function updateDOMProperties(
375380
}
376381
}
377382

378-
export function createElement(
383+
// Creates elements in the HTML namesapce
384+
export function createHTMLElement(
379385
type: string,
380386
props: Object,
381-
rootContainerElement: Element | Document | DocumentFragment,
382-
parentNamespace: string,
387+
ownerDocument: Document,
383388
): Element {
384389
let isCustomComponentTag;
385390

386-
// We create tags in the namespace of their parent container, except HTML
387-
// tags get no namespace.
388-
const ownerDocument: Document =
389-
getOwnerDocumentFromRootContainer(rootContainerElement);
390391
let domElement: Element;
391-
let namespaceURI = parentNamespace;
392-
if (namespaceURI === HTML_NAMESPACE) {
393-
namespaceURI = getIntrinsicNamespace(type);
392+
if (__DEV__) {
393+
isCustomComponentTag = isCustomComponent(type, props);
394+
// Should this check be gated by parent namespace? Not sure we want to
395+
// allow <SVG> or <mATH>.
396+
if (!isCustomComponentTag && type !== type.toLowerCase()) {
397+
console.error(
398+
'<%s /> is using incorrect casing. ' +
399+
'Use PascalCase for React components, ' +
400+
'or lowercase for HTML elements.',
401+
type,
402+
);
403+
}
394404
}
395-
if (namespaceURI === HTML_NAMESPACE) {
405+
406+
if (type === 'script') {
407+
// Create the script via .innerHTML so its "parser-inserted" flag is
408+
// set to true and it does not execute
409+
const div = ownerDocument.createElement('div');
396410
if (__DEV__) {
397-
isCustomComponentTag = isCustomComponent(type, props);
398-
// Should this check be gated by parent namespace? Not sure we want to
399-
// allow <SVG> or <mATH>.
400-
if (!isCustomComponentTag && type !== type.toLowerCase()) {
411+
if (enableTrustedTypesIntegration && !didWarnScriptTags) {
401412
console.error(
402-
'<%s /> is using incorrect casing. ' +
403-
'Use PascalCase for React components, ' +
404-
'or lowercase for HTML elements.',
405-
type,
413+
'Encountered a script tag while rendering React component. ' +
414+
'Scripts inside React components are never executed when rendering ' +
415+
'on the client. Consider using template tag instead ' +
416+
'(https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template).',
406417
);
418+
didWarnScriptTags = true;
407419
}
408420
}
409-
410-
if (type === 'script') {
411-
// Create the script via .innerHTML so its "parser-inserted" flag is
412-
// set to true and it does not execute
413-
const div = ownerDocument.createElement('div');
414-
if (__DEV__) {
415-
if (enableTrustedTypesIntegration && !didWarnScriptTags) {
416-
console.error(
417-
'Encountered a script tag while rendering React component. ' +
418-
'Scripts inside React components are never executed when rendering ' +
419-
'on the client. Consider using template tag instead ' +
420-
'(https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template).',
421-
);
422-
didWarnScriptTags = true;
423-
}
424-
}
425-
div.innerHTML = '<script><' + '/script>'; // eslint-disable-line
426-
// This is guaranteed to yield a script element.
427-
const firstChild = ((div.firstChild: any): HTMLScriptElement);
428-
domElement = div.removeChild(firstChild);
429-
} else if (typeof props.is === 'string') {
430-
domElement = ownerDocument.createElement(type, {is: props.is});
431-
} else {
432-
// Separate else branch instead of using `props.is || undefined` above because of a Firefox bug.
433-
// See discussion in https://github.com/facebook/react/pull/6896
434-
// and discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1276240
435-
domElement = ownerDocument.createElement(type);
436-
// Normally attributes are assigned in `setInitialDOMProperties`, however the `multiple` and `size`
437-
// attributes on `select`s needs to be added before `option`s are inserted.
438-
// This prevents:
439-
// - a bug where the `select` does not scroll to the correct option because singular
440-
// `select` elements automatically pick the first item #13222
441-
// - a bug where the `select` set the first item as selected despite the `size` attribute #14239
442-
// See https://github.com/facebook/react/issues/13222
443-
// and https://github.com/facebook/react/issues/14239
444-
if (type === 'select') {
445-
const node = ((domElement: any): HTMLSelectElement);
446-
if (props.multiple) {
447-
node.multiple = true;
448-
} else if (props.size) {
449-
// Setting a size greater than 1 causes a select to behave like `multiple=true`, where
450-
// it is possible that no option is selected.
451-
//
452-
// This is only necessary when a select in "single selection mode".
453-
node.size = props.size;
454-
}
421+
div.innerHTML = '<script><' + '/script>'; // eslint-disable-line
422+
// This is guaranteed to yield a script element.
423+
const firstChild = ((div.firstChild: any): HTMLScriptElement);
424+
domElement = div.removeChild(firstChild);
425+
} else if (typeof props.is === 'string') {
426+
domElement = ownerDocument.createElement(type, {is: props.is});
427+
} else {
428+
// Separate else branch instead of using `props.is || undefined` above because of a Firefox bug.
429+
// See discussion in https://github.com/facebook/react/pull/6896
430+
// and discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1276240
431+
domElement = ownerDocument.createElement(type);
432+
// Normally attributes are assigned in `setInitialDOMProperties`, however the `multiple` and `size`
433+
// attributes on `select`s needs to be added before `option`s are inserted.
434+
// This prevents:
435+
// - a bug where the `select` does not scroll to the correct option because singular
436+
// `select` elements automatically pick the first item #13222
437+
// - a bug where the `select` set the first item as selected despite the `size` attribute #14239
438+
// See https://github.com/facebook/react/issues/13222
439+
// and https://github.com/facebook/react/issues/14239
440+
if (type === 'select') {
441+
const node = ((domElement: any): HTMLSelectElement);
442+
if (props.multiple) {
443+
node.multiple = true;
444+
} else if (props.size) {
445+
// Setting a size greater than 1 causes a select to behave like `multiple=true`, where
446+
// it is possible that no option is selected.
447+
//
448+
// This is only necessary when a select in "single selection mode".
449+
node.size = props.size;
455450
}
456451
}
457-
} else {
458-
domElement = ownerDocument.createElementNS(namespaceURI, type);
459452
}
460453

461454
if (__DEV__) {
462-
if (namespaceURI === HTML_NAMESPACE) {
463-
if (
464-
!isCustomComponentTag &&
465-
// $FlowFixMe[method-unbinding]
466-
Object.prototype.toString.call(domElement) ===
467-
'[object HTMLUnknownElement]' &&
468-
!hasOwnProperty.call(warnedUnknownTags, type)
469-
) {
470-
warnedUnknownTags[type] = true;
471-
console.error(
472-
'The tag <%s> is unrecognized in this browser. ' +
473-
'If you meant to render a React component, start its name with ' +
474-
'an uppercase letter.',
475-
type,
476-
);
477-
}
455+
if (
456+
!isCustomComponentTag &&
457+
// $FlowFixMe[method-unbinding]
458+
Object.prototype.toString.call(domElement) ===
459+
'[object HTMLUnknownElement]' &&
460+
!hasOwnProperty.call(warnedUnknownTags, type)
461+
) {
462+
warnedUnknownTags[type] = true;
463+
console.error(
464+
'The tag <%s> is unrecognized in this browser. ' +
465+
'If you meant to render a React component, start its name with ' +
466+
'an uppercase letter.',
467+
type,
468+
);
478469
}
479470
}
480471

481472
return domElement;
482473
}
483474

475+
export function createSVGElement(
476+
type: string,
477+
ownerDocument: Document,
478+
): Element {
479+
return ownerDocument.createElementNS(SVG_NAMESPACE, type);
480+
}
481+
482+
export function createMathElement(
483+
type: string,
484+
ownerDocument: Document,
485+
): Element {
486+
return ownerDocument.createElementNS(MATH_NAMESPACE, type);
487+
}
488+
484489
export function createTextNode(
485490
text: string,
486491
rootContainerElement: Element | Document | DocumentFragment,
@@ -864,9 +869,9 @@ export function diffHydratedProperties(
864869
domElement: Element,
865870
tag: string,
866871
rawProps: Object,
867-
parentNamespace: string,
868872
isConcurrentMode: boolean,
869873
shouldWarnDev: boolean,
874+
parentNamespaceDev: string,
870875
): null | Array<mixed> {
871876
let isCustomComponentTag;
872877
let extraAttributeNames: Set<string>;
@@ -1109,11 +1114,11 @@ export function diffHydratedProperties(
11091114
propertyInfo,
11101115
);
11111116
} else {
1112-
let ownNamespace = parentNamespace;
1113-
if (ownNamespace === HTML_NAMESPACE) {
1114-
ownNamespace = getIntrinsicNamespace(tag);
1117+
let ownNamespaceDev = parentNamespaceDev;
1118+
if (ownNamespaceDev === HTML_NAMESPACE) {
1119+
ownNamespaceDev = getIntrinsicNamespace(tag);
11151120
}
1116-
if (ownNamespace === HTML_NAMESPACE) {
1121+
if (ownNamespaceDev === HTML_NAMESPACE) {
11171122
// $FlowFixMe - Should be inferred as not undefined.
11181123
extraAttributeNames.delete(propKey.toLowerCase());
11191124
} else {

0 commit comments

Comments
 (0)