New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 608006 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Dojo webapp - slower load times and new errors in console

Reported by ofer.eck...@gmail.com, Apr 29 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. This is a private enterprise app, but I would imagine that other dojo apps would have the same issue.

What is the expected behavior?
no errors (stable chrome version), much faster load time (stable chrome version).

What went wrong?
application load time significantly longer in beta and dev channels. Errors are shown in console. Not sure if any features actually stopped working but the whole app is slower.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? N/A 

Did this work before? Yes Currently - stable channel 50.0.2661.94 m

Does this work in other browsers? Yes 

Chrome version: 50.0.2704.29  Channel: beta
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 21.0 r0

There was a bug a couple of months back (https://bugs.chromium.org/p/chromium/issues/detail?id=570622) that affected a lot of dojo applications and it made it to a stable release. Ever since then I've been using the DEV channel, so I can get ahead of the curve on these bugs that can severely disrupt production. I think this may be one. I'll be glad to provide more information if needed.
 
beta-channel.png
46.7 KB View Download
dev-channel.png
46.1 KB View Download
The page elements that are reporting the errors are in fact being disrupted. So in addition to slow speed and errors in console, there is a also a reduction in usability (radiobuttons showing as text fields with filled in numbers, for example, from another app).
I've created a small app to demonstrate this issue (https://radiobuttongroup.herokuapp.com/)

please view in stable version and in beta and see the differences (also consult the console log)

it has to do with a certain radiobutton group widget for Wavemaker (it may not apply to all dojo...). For my purposes it's a fairly easy fix, so I'm going to go ahead and implement the fix, but it is nonetheless regression in functionality. 
radiobuttons.png
10.0 KB View Download

Comment 3 by ajha@chromium.org, May 3 2016

Cc: ajha@chromium.org
Components: Blink>WebComponents
Labels: -Pri-2 -Type-Compat ReleaseBlock-Stable M-51 hasbisect OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: yuzus@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this on the latest canary(52.0.2723.0) and the latest beta(51.0.2704.29) on Windows-7, Mac OS 10.11.4 and Linux Ubuntu 14.04.

This is a regression issue broken in M-51.

Last good build: 51.0.2673.0
First bad build: 51.0.2674.0

Changelog:
=========
https://chromium.googlesource.com/chromium/src/+log/740c4109f954a11c544c02132a89fabab767e7ab..9ca99ec409a1d6f7baf6dd3cd6929e81c967cac1

Suspecting: https://codereview.chromium.org/1783693002

yuzus@: Could you please take a look if the change is related.

Thank you!

Comment 4 by ajha@chromium.org, May 4 2016

Cc: hayato@chromium.org
Gentle ping to get an update on this Stable blocker. Cc'ing reviewer as well for more inputs.
Cc: -ajha@chromium.org -hayato@chromium.org
Labels: -hasbisect Needs-Bisect
Owner: ajha@chromium.org
The change is unlikely to be the culprit. This could be a bad bisect -- could you please double-check? Also, the team you're trying to reach is in Tokyo, and most of Japan is on holiday this week.
Cc: ajha@chromium.org
Owner: hayato@chromium.org
Oh you know what? I am wrong. This is definitely a compat regression. Turns out, Dojo sets node.rootNode on an Element :(

From the sample app:

if(!args&&_483&&_483.rootNode){
args=_483;
root=args.rootNode;
}else{
root=_483;
}
See also  bug 600950 .

Comment 8 by ajha@chromium.org, May 5 2016

Cc: yuzus@chromium.org
Labels: -Needs-Bisect
Bisect already provided and owner assigned, hence removing the bisect label.
Please get the revert merged to M51.
A friendly reminder that M51 Stable is launching soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch by May 17. All changes MUST be merged into the release branch by 5pm on May 20 to make into the desktop Stable final build cut. Thanks!
Cc: kochi@chromium.org

Comment 13 by kochi@chromium.org, May 10 2016

Labels: Merge-Request-51

Comment 14 by kochi@chromium.org, May 10 2016

As in comment #9, the fix is revert CL
https://codereview.chromium.org/1945823004/
which is on canary/dev for a few days.

Requesting for merge to Beta M51.

Comment 15 by kochi@chromium.org, May 10 2016

Note that the original shipment was
https://chromium.googlesource.com/chromium/src.git/+/9ca99ec409a1d6f7baf6dd3cd6929e81c967cac1
on Mar. 10, 2016, which was for M51.
M50 stable is not affected.

Comment 16 by tin...@google.com, May 10 2016

Labels: -Merge-Request-51 Merge-Approved-51 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M51 (branch: 2704)
Project Member

Comment 17 by bugdroid1@chromium.org, May 11 2016

Labels: -merge-approved-51 merge-merged-2704
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f0a505bf8131eb3bff547835f89dd3036ab5c90f

commit f0a505bf8131eb3bff547835f89dd3036ab5c90f
Author: Takayoshi Kochi <kochi@chromium.org>
Date: Wed May 11 01:32:33 2016

Revert of Ship Node.rootNode (patchset #2 id:20001 of https://codereview.chromium.org/1783693002/ )

Reason for revert:
Turns out that the change is not Web-compatible. See https://bugs.chromium.org/p/chromium/issues/detail?id=608006 for details.

Original issue's description:
> Ship Node.rootNode
>
> This CL ships Node.rootNode independently from other ShadowDOM features, in response to requests from web developers.
> LGTM-ed on this thread :  https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/LpXX7Svx8IY
>
> BUG= 531990 
>
> Committed: https://crrev.com/9ca99ec409a1d6f7baf6dd3cd6929e81c967cac1
> Cr-Commit-Position: refs/heads/master@{#380363}

TBR=tkent@chromium.org,hayato@chromium.org,kochi@chromium.org,yuzus@chromium.org
BUG= 531990 ,  608006 

Review-Url: https://codereview.chromium.org/1945823004
Cr-Commit-Position: refs/heads/master@{#391723}
(cherry picked from commit 08405679e3c56b833b4c6da3135b30485fad279b)

Review URL: https://codereview.chromium.org/1962403004 .

Cr-Commit-Position: refs/branch-heads/2704@{#492}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/f0a505bf8131eb3bff547835f89dd3036ab5c90f/third_party/WebKit/LayoutTests/virtual/stable/webexposed/element-instance-property-listing-expected.txt
[modify] https://crrev.com/f0a505bf8131eb3bff547835f89dd3036ab5c90f/third_party/WebKit/LayoutTests/virtual/stable/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/f0a505bf8131eb3bff547835f89dd3036ab5c90f/third_party/WebKit/Source/core/dom/Node.idl

Comment 18 by kochi@chromium.org, May 11 2016

Status: Fixed (was: Assigned)

Sign in to add a comment