901632 - Matrix Airfare Search (Itasoftware): search form is not shown

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Mathieu Marquer]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20130805030205

Steps to reproduce:

Going on http://matrix.itasoftware.com/


Actual results:

A search form should appear on the left


Expected results:

A blank space is where the search form should be. Tried in safe mode, same result. Tried with Google Chrome, it works there.

Comment 1

[Mathieu Marquer]

Actually works on Google Chrome stable, but not on Google Chrome dev (30.0). Might be a website bug then.

Comment 2

[Loic]

Bug confirmed, maybe TE bug.

good=2013-07-23
bad=2013-07-24
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5ceea82a79c7&tochange=2983ca6d4d1a

Comment 3

[Alice0775 White]

An error in BrowserConsole:
[object Error] dojo.js

Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c4d279b10128&tochange=3c811f1e3d12

Comment 4

[Boris Zbarsky [:bzbarsky]]

The bug only appears if nextElementSibling is defined on ChildNode.  If I move that back to Element, the bug disappears.

That would be consistent with the Chrome behavior described in comment 1: they must have recently added nextElementSibling on non-Elements as well.

Looking into what the site is doing.

Comment 5

[Boris Zbarsky [:bzbarsky]]

The dojo.js bits on this site have:

            var _1e1 = (typeof _1ba().firstChild.nextElementSibling == "undefined");
            var _1e2 = !_1e1 ? "nextElementSibling" : "nextSibling";
            var _1e3 = !_1e1 ? "previousElementSibling" : "previousSibling";
            var _1e4 = (_1e1 ? _1d6 : _1bf);

In this case, _1ba() returns the document.  Its firstChild is the DocumentType.  The DOM spec has "DocumentType implements ChildNode" so this suddenly has a nextElementSibling that's not undefined.

So in the old world, we ended up setting:

            var _1e1 = true;
            var _1e2 = "nextSibling";
            var _1e3 = "previousSibling";
            var _1e4 = _1d6;

and in the new world we get:

            var _1e1 = false;
            var _1e2 = "nextElementSibling";
            var _1e3 = "previousElementSibling";
            var _1e4 = _1bf;

We also have:

            var _1d6 = function (n) {
                return (1 == n.nodeType);
            };

            var _1bf = function () {
                return true;
            };

I haven't figured out how these are used yet and where things might go wrong, but it looks like current dojo has code very much like this....

Comment 6

[Boris Zbarsky [:bzbarsky]]

Well, the uses of _1e1, _1e2, _1e3 all look reasonable.  There is one questionable use of _1e4, though:

            var _200 = function (_201) {
                _201 = _201 || _1bf;
                return function (root, ret, bag) {
                    var te, x = 0,
                        tret = root[_1bc];
                    while (te = tret[x++]) {
                        if (_1e4(te) && (!bag || _1fd(te, bag)) && (_201(te, x))) {
                            ret.push(te);
                        }
                    }
                    return ret;
                };
            };

here _1bc is defined as:

            var _1bc = !! _1ba().firstChild["children"] ? "children" : "childNodes";

But a DocumentType does not have a "children" property, so _1bc is "childNodes".  So this function used to have a loop that only considered elements, but now it considers _all_ child nodes (note that _1e4 always returns true in the new world).  I expect that's where things go awry.

Comment 7

[Boris Zbarsky [:bzbarsky]]

I _think_ current dojo has fixed that last bit to use "root.children || root.childNodes" instead of "root[_1bc]", so it's possible that the site updating dojo would help.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Well, we need to either get this site to fix (and hope no other sites are affected?) or change the spec and back out .nextElementSibling on DocumentType.

Note the Chrome issue for this at https://code.google.com/p/chromium/issues/detail?id=246609

Comment 9

[Boris Zbarsky [:bzbarsky]]

Mathieu, are you possibly a customer of this site?  Would you be able to contact them to let them know about this problem?

Comment 10

[Mathieu Marquer]

I'm not really a customer, I just use their search engine which is available for free (they don't actually sell plane tickets). But since this website has been acquired by Google last year, I guess Chrome devs would contact them pretty easily ;)

I'll email them anyway, maybe it can help. Thanks for tracking down this bug.

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Google owns them, we should bring this up on mozilla-google-discuss.

/me sees midair with Mathieu

Comment 12

[Mathieu Marquer]

I opened a "bug" on their forum: https://productforums.google.com/forum/#!topic/matrixandonthefly/kbAmhSisMdM (they say this is where bugs should be reported).

Comment 13

[Boris Zbarsky [:bzbarsky]]

I sent some mail too.

Comment 14

[Mathieu Marquer]

Fixed on their side.