Able to reproduce this issue on reported verison 62.0.3202.75 and on latest canary 64.0.3256.0 using Windows 10,Ubuntu 14.04 and Mac 10.12.6 with steps mentioned in comment#0. Issue is seen in firefox as well.

This issue is seen from M50[50.0.2661.0]. Hence considering this as Non-regression and marking this as Untriaged

Given that it has been broken for over ten releases and is also broken in Firefox I'd assume this was due to an intentional web compat change. Does it work in Safari or Edge?

It does work correctly in Safari and Edge.

Have you contacted Dojo project itself?
If they have any idea where is broken in Firefox and Chrome, we may able to fix the issue
(if this is a real compat issue).

BTW, I tried this (with modification on line 9, adding https: schema to the URL) on
Chrome 62 and Safari 11.0.1, and both failed with similar error message and only
saw black screen.

Chrome:
> Uncaught TypeError: this.transitionTo is not a function
Safari:
> TypeError: this.transitionTo is not a function. (In 'this.transitionTo("logIn")', 'this.transitionTo' is undefined)

I can't believe I left that test code in there. There is no reason to have the transitionTo logic. The thing should just work as it is. I'll attach a new and simpler version that does reproduce the issue. I did test this with Dojo 1.13.0 and the problem remains. Interestingly, Dojo version 1.7 seems to work. I need to do more testing to confirm this. The reason it was undiscovered for so long is that, on Windows, Chrome never insisted upon an upgrade until version 62.0. I suspect that this issue will become fairly common now that the user base is upgrading Chrome.

I have not contacted Dojo. I will... but this really looks like a Chrome issue. It works with Edge.

Deleted: test.html 1.5 KB

test.html 1.5 KB View Download

Thanks for uploading the test!
I think I reproduced the issue locally (Mac Chrome, M62 here).

1. Open test.html
2. See only solid black screen
3. Resize the window by narrowing enough to see "Log in" UI

(View source didn't work for me, btw).
I'd also thank if Dojo people have any clue what is happening here.

As the reporter says it worked before and at least 62.0.3202 the case does not work -
marking this as regression.

Can we have bisect info for this?

We found a javascript / dojo fix for this. The original code attempted to parse the DOM prior to the browser having the DOM ready. 

The new code should be:

    <script>
        require([
            "dojox/mobile/parser",
            "dojo/ready",
            "dojox/mobile/View",
            "dojox/mobile/Heading"

        ], function (parser, ready) {
            ready(function () {
                parser.parse();
            })


        });
    </script>

Now, we wait for the DOM to be ready prior to parsing it. 

So, it turns out this was a timing issue. I suspect this issue can now be closed since we have a best practice within the dojo framework to deal with exactly this issue.

Thank you for your attention.

Thanks for the feedback!  We really appreciate you found the solution yourself.

Just in case this is a real regression that timing change caused some
incompatibility, I'd like to wait for bisect analysis before closing this.

Isn't "Needs-Bisect" flag enough to ask someone in testing team to do
bisection for this issue?

Able to reproduce this issue on reported version 62.0.3202.75 and on latest stable 62.0.3202.94 but fixed on latest beta 63.0.3239.52 and latest dev 64.0.3269.3 using Windows 10, Ubuntu 14.04 and Mac 10.12.6. Hence Providing reverse bisect info.

Reverse Bisect Info:
================
Last Bad Build: 63.0.3225.0
First Good Build: 63.0.3226.0 

You are probably looking for a change made after 504560 (known good), but no later than 504561 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/a9ba55c8571ab0d2624c83d413ccc7215a185f51..9f0c480da9cb188c82e16e6c6751875a60a114cf

Probably fixed by : https://chromium-review.googlesource.com/684186

@rune:Could you please confirm if its safe to merge to M-62 in case we have stable refresh?

Unable to assign to @rune. Hence assigning to @treib: Please check the above issue.

Thanks!

Duplicate of  issue 785233 . We considered it to be to risky to backport to 62 because there are multiple patches which would need to be merged, and 63 going stable on December 5th.