Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Text adjacent to radio button that is not wrapped in any tag results in a minified exception #6705

Closed
jineshshah36 opened this issue May 5, 2016 · 13 comments
Labels
Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug

Comments

@jineshshah36
Copy link

This:

<label><input type={'radio'} />{props.children}</label>

results in a minified exception that is nearly impossible to debug because it tells me to switch to development mode; however, I receive no errors in development mode.

This:

<label><input type={'radio'} /><div>{props.children}</div></label>

does not result in any errors.

I am not sure what the problem here is, but I just spent 6 hours trying to debug this issue, so I figured I should bring it to your attention.

@jimfb
Copy link
Contributor

jimfb commented May 5, 2016

This is not enough information for this issue to be actionable. Can you reproduce the bug in a minimal repro/jsfiddle?

@syranide
Copy link
Contributor

syranide commented May 5, 2016

@jineshshah36 If you put a breakpoint on the error you can usually quite easily see where the error is originating from and look up the actual error from the development build.

@DiscoStarslayer
Copy link

There must be something outside of this causing the bug, I tried to reproduce in this JSFiddle and cannot.

@jimfb jimfb added the Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug label May 5, 2016
@zpao
Copy link
Member

zpao commented May 5, 2016

I think the determining factor will be what the value of props.children is at that point. I haven't looked to see if there are node types that aren't valid in labels but that's my best guess.

@jimfb
Copy link
Contributor

jimfb commented May 17, 2016

No response from OP.

@jimfb jimfb closed this as completed May 17, 2016
@jineshshah36
Copy link
Author

Hi, sorry I was traveling and this got lost. Essentially, I'm having trouble figuring out a way to replicate this to you guys. The main issue is that the exception only occurs when minified and in production. So whenever I check the development version, there are no errors

@jineshshah36
Copy link
Author

I did some digging and tried to follow @syranide advice. I am having a similar issue with an img tag and was able to trace it to this function

   /**
     * Populate `_nativeNode` on each child of `inst`, assuming that the children
     * match up with the DOM (element) children of `node`.
     *
     * We cache entire levels at once to avoid an n^2 problem where we access the
     * children of a node sequentially and have to walk from the start to our target
     * node every time.
     *
     * Since we update `_renderedChildren` and the actual DOM at (slightly)
     * different times, we could race here and see a newer `_renderedChildren` than
     * the DOM nodes we see. To avoid this, ReactMultiChild calls
     * `prepareToManageChildren` before we change `_renderedChildren`, at which
     * time the container's child nodes are always cached (until it unmounts).
     */
        function precacheChildNodes(inst, node) {
            if (inst._flags & Flags.hasCachedChildNodes) {
                return;
            }
            var children = inst._renderedChildren;
            var childNode = node.firstChild;
            outer: for (var name in children) {
                if (!children.hasOwnProperty(name)) {
                    continue;
                }
                var childInst = children[name];
                var childID = getRenderedNativeOrTextFromComponent(childInst)._domID;
                if (childID == null ) {
                    // We're currently unmounting this child in ReactMultiChild; skip it.
                    continue;
                }
                // We assume the child nodes are in the same order as the child instances.
                for (; childNode !== null ; childNode = childNode.nextSibling) {
                    if (childNode.nodeType === 1 && childNode.getAttribute(ATTR_NAME) === String(childID) || childNode.nodeType === 8 && childNode.nodeValue === ' react-text: ' + childID + ' ' || childNode.nodeType === 8 && childNode.nodeValue === ' react-empty: ' + childID + ' ') {
                        precacheNode(childInst, childNode);
                        continue outer;
                    }
                }
                // We reached the end of the DOM children without finding an ID match.
                true ? process.env.NODE_ENV !== 'production' ? invariant(false, 'Unable to find element with ID %s.', childID) : invariant(false) : void 0;
            }
            inst._flags |= Flags.hasCachedChildNodes;
        }

The line that is in the stacktrace is this one:

 true ? process.env.NODE_ENV !== 'production' ? invariant(false, 'Unable to find element with ID %s.', childID) : invariant(false) : void 0;

The invariant(false) piece is what runs because I am in production

@texttechne
Copy link

So in dev mode it should throw an invariant violation exception with the message Unable to find element with ID xxx.
What does childId evaluate to at this point?
And what is the contents of props.children?

@gaearon
Copy link
Collaborator

gaearon commented May 18, 2016

@jineshshah36 Can you please try to reproduce this with a version of React compiled from master? You can grab one from http://react.zpao.com/builds/master/latest/.

@jineshshah36
Copy link
Author

Hey guys, so I found the culprit. I still don't quite understand why, but Cloudflare was causing the issues. Cloudflare was re-minifying my already minified script which was causing some sort of issue that lead to weird errors like this. Thanks for everyone's help, but everything looks to be working now.

@zpao
Copy link
Member

zpao commented May 19, 2016

Thanks for following up. If you do figure out what Cloudflare might have been doing to break in such a way, let us know. We might want to work with them to ensure it doesn't happen to others.

@zpao
Copy link
Member

zpao commented May 19, 2016

Potentially related to #5753 (comment) if you're mounting server-rendered markup.

@jineshshah36
Copy link
Author

I'll investigate further to see if #5753 is related

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug
Projects
None yet
Development

No branches or pull requests

7 participants