Set up serving infrastructure for c/b/r/settings.

Set up serving infrastructure for c/b/r/settings.

BUG=

Committed: https://crrev.com/794e9820dc79d9c94734e87ed73f7a46faa15666
Cr-Commit-Position: refs/heads/master@{#319512}

[Jeremy Klein, 2015-03-06 00:09:30]

https://codereview.chromium.org/985533002/diff/1/tools/gritsettings/resource_ids
File tools/gritsettings/resource_ids (right):

https://codereview.chromium.org/985533002/diff/1/tools/gritsettings/resource_...
tools/gritsettings/resource_ids:249: "structures": [30900],
What happens when we run out of room here? See line 260.

[Jeremy Klein, 2015-03-06 00:11:33]

jlklein@chromium.org changed reviewers:
+ jhawkins@chromium.org, michaelpg@chromium.org, stevenjb@chromium.org

[Jeremy Klein, 2015-03-06 00:14:08]

This CL causes everything under chrome/browser/resources/settings to be served
to chrome://md-settings/* as long as it's in settings_resources.grd. I'd like to
write a script to generate the structures in settings_resources.grd so that we
don't need to manually add html, js, css every time we add a component.

[Dan Beam, 2015-03-06 00:53:24]

drive-by

https://codereview.chromium.org/985533002/diff/20001/chrome/browser/resources...
File chrome/browser/resources/settings/a11y_page/demo.js (right):

https://codereview.chromium.org/985533002/diff/20001/chrome/browser/resources...
chrome/browser/resources/settings/a11y_page/demo.js:3: * found in the LICENSE
file. */
.js files should have

  // Copyright...

single-line style comments

[Jeremy Klein, 2015-03-06 01:44:57]

https://codereview.chromium.org/985533002/diff/20001/chrome/browser/resources...
File chrome/browser/resources/settings/a11y_page/demo.js (right):

https://codereview.chromium.org/985533002/diff/20001/chrome/browser/resources...
chrome/browser/resources/settings/a11y_page/demo.js:3: * found in the LICENSE
file. */
On 2015/03/06 00:53:24, Dan Beam wrote:
> .js files should have
> 
>   // Copyright...
> 
> single-line style comments

Done.

[michaelpg, 2015-03-06 02:08:17]

fwiw, LGTM *but* I don't have a good understanding of how this stuff works :-)

https://codereview.chromium.org/985533002/diff/1/chrome/browser/resources/set...
File chrome/browser/resources/settings/prefs/prefs.js (right):

https://codereview.chromium.org/985533002/diff/1/chrome/browser/resources/set...
chrome/browser/resources/settings/prefs/prefs.js:78: /**
Looks like there's an extra space on this line

https://codereview.chromium.org/985533002/diff/1/chrome/browser/resources/set...
chrome/browser/resources/settings/prefs/prefs.js:85: return
camelCaseName.replace(/([A-Z])/g, function($1) {
let's avoid using $ in variable/parameter names, especially with Polymer's use
of $

https://codereview.chromium.org/985533002/diff/1/chrome/browser/ui/webui/md_s...
File chrome/browser/ui/webui/md_settings_ui.cc (right):

https://codereview.chromium.org/985533002/diff/1/chrome/browser/ui/webui/md_s...
chrome/browser/ui/webui/md_settings_ui.cc:29:
html_source->AddResourcePath(resource_name, resource_id);
nit: just call the function directly without creating automatic variables?

https://codereview.chromium.org/985533002/diff/1/chrome/chrome_browser.gypi
File chrome/chrome_browser.gypi (right):

https://codereview.chromium.org/985533002/diff/1/chrome/chrome_browser.gypi#n...
chrome/chrome_browser.gypi:3092:
'<(grit_out_dir)/grit/settings_resources_map.cc',
nit: I think we tend to keep gyp files alphabetical, can this go above the
previous line?

https://codereview.chromium.org/985533002/diff/1/chrome/chrome_repack_resourc...
File chrome/chrome_repack_resources.gypi (right):

https://codereview.chromium.org/985533002/diff/1/chrome/chrome_repack_resourc...
chrome/chrome_repack_resources.gypi:44:
'<(grit_out_dir)/settings_resources.pak',
ok, maybe I'm wrong about alphabetization

[Jeremy Klein, 2015-03-06 02:20:01]

https://codereview.chromium.org/985533002/diff/1/chrome/browser/resources/set...
File chrome/browser/resources/settings/prefs/prefs.js (right):

https://codereview.chromium.org/985533002/diff/1/chrome/browser/resources/set...
chrome/browser/resources/settings/prefs/prefs.js:78: /**
On 2015/03/06 02:08:17, michaelpg wrote:
> Looks like there's an extra space on this line

Done.

https://codereview.chromium.org/985533002/diff/1/chrome/browser/resources/set...
chrome/browser/resources/settings/prefs/prefs.js:85: return
camelCaseName.replace(/([A-Z])/g, function($1) {
On 2015/03/06 02:08:17, michaelpg wrote:
> let's avoid using $ in variable/parameter names, especially with Polymer's use
> of $

Done.

https://codereview.chromium.org/985533002/diff/1/chrome/browser/ui/webui/md_s...
File chrome/browser/ui/webui/md_settings_ui.cc (right):

https://codereview.chromium.org/985533002/diff/1/chrome/browser/ui/webui/md_s...
chrome/browser/ui/webui/md_settings_ui.cc:29:
html_source->AddResourcePath(resource_name, resource_id);
On 2015/03/06 02:08:17, michaelpg wrote:
> nit: just call the function directly without creating automatic variables?

Done.

https://codereview.chromium.org/985533002/diff/1/chrome/chrome_browser.gypi
File chrome/chrome_browser.gypi (right):

https://codereview.chromium.org/985533002/diff/1/chrome/chrome_browser.gypi#n...
chrome/chrome_browser.gypi:3092:
'<(grit_out_dir)/grit/settings_resources_map.cc',
On 2015/03/06 02:08:17, michaelpg wrote:
> nit: I think we tend to keep gyp files alphabetical, can this go above the
> previous line?

Done.

https://codereview.chromium.org/985533002/diff/1/chrome/chrome_repack_resourc...
File chrome/chrome_repack_resources.gypi (right):

https://codereview.chromium.org/985533002/diff/1/chrome/chrome_repack_resourc...
chrome/chrome_repack_resources.gypi:44:
'<(grit_out_dir)/settings_resources.pak',
On 2015/03/06 02:08:17, michaelpg wrote:
> ok, maybe I'm wrong about alphabetization

*Shrug*... alphabetized.

[stevenjb, 2015-03-06 18:03:52]

The changes to prefs.js and cr_dropdown_menu.js seem unrelated and should be
committed separately. Otherwise lgtm.

[Jeremy Klein, 2015-03-06 18:25:13]

On 2015/03/06 18:03:52, stevenjb wrote:
> The changes to prefs.js and cr_dropdown_menu.js seem unrelated and should be
> committed separately. Otherwise lgtm.

Removed. Not even sure how the dropdown stuff got into this cl haha.

[James Hawkins, 2015-03-06 18:44:12]

https://codereview.chromium.org/985533002/diff/140001/chrome/browser/resource...
File chrome/browser/resources/settings/a11y_page/demo.html (right):

https://codereview.chromium.org/985533002/diff/140001/chrome/browser/resource...
chrome/browser/resources/settings/a11y_page/demo.html:10: <script
src="demo.js"></script>
Is this required to be in the body?

[Jeremy Klein, 2015-03-06 18:48:33]

https://codereview.chromium.org/985533002/diff/140001/chrome/browser/resource...
File chrome/browser/resources/settings/a11y_page/demo.html (right):

https://codereview.chromium.org/985533002/diff/140001/chrome/browser/resource...
chrome/browser/resources/settings/a11y_page/demo.html:10: <script
src="demo.js"></script>
On 2015/03/06 18:44:12, James Hawkins wrote:
> Is this required to be in the body?

Nope. It's just a web-dev best practice to put scripts at the bottom for loading
speed, but it really really doesn't matter here. I guess I've been getting too
used to Polymer html files :-). Moved to head.

[James Hawkins, 2015-03-06 18:50:53]

lgtm

[Jeremy Klein, 2015-03-06 18:51:44]

The CQ bit was checked by jlklein@chromium.org

[Jeremy Klein, 2015-03-06 18:51:45]

The patchset sent to the CQ was uploaded after l-g-t-m from
michaelpg@chromium.org, stevenjb@chromium.org
Link to the patchset: https://codereview.chromium.org/985533002/#ps160001
(title: "Move demo script tag to head.")

[commit-bot: I haz the power, 2015-03-06 18:52:19]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/985533002/160001

[Jeremy Klein, 2015-03-06 20:11:53]

The CQ bit was unchecked by jlklein@chromium.org

[Jeremy Klein, 2015-03-06 20:18:51]

The CQ bit was checked by jlklein@chromium.org

[Jeremy Klein, 2015-03-06 20:18:51]

The patchset sent to the CQ was uploaded after l-g-t-m from
stevenjb@chromium.org, jhawkins@chromium.org, michaelpg@chromium.org
Link to the patchset: https://codereview.chromium.org/985533002/#ps180001
(title: "Wait for onload.")

[michaelpg, 2015-03-06 20:25:59]

https://codereview.chromium.org/985533002/diff/180001/chrome/browser/resource...
File chrome/browser/resources/settings/a11y_page/demo.js (right):

https://codereview.chromium.org/985533002/diff/180001/chrome/browser/resource...
chrome/browser/resources/settings/a11y_page/demo.js:8: window.onload =
function() {
I believe it's more "correct" to use window.addEventListener('polymer-ready',
...) to ensure the elements have been registered.

[commit-bot: I haz the power, 2015-03-06 20:31:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/985533002/180001

[Jeremy Klein, 2015-03-06 21:33:56]

https://codereview.chromium.org/985533002/diff/180001/chrome/browser/resource...
File chrome/browser/resources/settings/a11y_page/demo.js (right):

https://codereview.chromium.org/985533002/diff/180001/chrome/browser/resource...
chrome/browser/resources/settings/a11y_page/demo.js:8: window.onload =
function() {
On 2015/03/06 20:25:59, michaelpg wrote:
> I believe it's more "correct" to use window.addEventListener('polymer-ready',
> ...) to ensure the elements have been registered.

This isn't really necessary in this case because the script here doesn't depend
on any of the Polymer elements being upgraded, just that the DOM is loaded.
Also, do you know if polymer-ready is guaranteed to fire *after* window.onload?
I know that it will probably almost always be true, but I'm not sure there's a
guarantee there. If we got into a state where the polymer-ready fired before
window.onload, we'd still hit errors in here.

I'll change it if you feel really strongly about it, but I think for a demo that
isn't actually relying on polymer elements being fully registered, this doesn't
matter much.

[commit-bot: I haz the power, 2015-03-06 21:43:51]

Committed patchset #10 (id:180001)

[commit-bot: I haz the power, 2015-03-06 21:44:27]

Patchset 10 (id:??) landed as
https://crrev.com/794e9820dc79d9c94734e87ed73f7a46faa15666
Cr-Commit-Position: refs/heads/master@{#319512}

[michaelpg, 2015-03-06 22:33:49]

@dfreedm, is this something you could help us with for future reference?

We're not sure whether it's 1. necessary and 2. sufficient to wait for
"polymer-ready" before setting properties on Polymer elements. I couldn't find a
great answer in the Polymer docs, sorry if it's there somewhere.

1. Do we need to wait for the element to be upgraded before setting properties
that are listed in the publish block?

2. Is the DOM itself guaranteed to be ready before "polymer-ready" is fired?

Thanks!

https://codereview.chromium.org/985533002/diff/180001/chrome/browser/resource...
File chrome/browser/resources/settings/a11y_page/demo.js (right):

https://codereview.chromium.org/985533002/diff/180001/chrome/browser/resource...
chrome/browser/resources/settings/a11y_page/demo.js:8: window.onload =
function() {
On 2015/03/06 21:33:56, Jeremy Klein wrote:
> On 2015/03/06 20:25:59, michaelpg wrote:
> > I believe it's more "correct" to use
window.addEventListener('polymer-ready',
> > ...) to ensure the elements have been registered.
> 
> This isn't really necessary in this case because the script here doesn't
depend
> on any of the Polymer elements being upgraded, just that the DOM is loaded.

Data binding seems to work, but apparently it's not going through all the
motions. If the element hasn't been upgraded, setting page.prefs just sets that
property (which is all the page needs for data binding to start kicking in).

Once the element has been upgraded, setting page.prefs would cause changed
watchers to be called, updates page.prefs_, and whatever else Polymer does under
the hood. If the attribute were reflected, the reflection wouldn't happen. So
all of that doesn't happen if the element hasn't been upgraded yet. I don't know
whether there's a guarantee in terms of what will work and what won't.

> Also, do you know if polymer-ready is guaranteed to fire *after*
window.onload?
> I know that it will probably almost always be true, but I'm not sure there's a
> guarantee there. If we got into a state where the polymer-ready fired before
> window.onload, we'd still hit errors in here.

I can't find that guarantee. But could polymer-ready be fired without the DOM?
My understanding is it can only be fired once all polymer-element declarations
have been executed. Can it ensure that before it's queried the entire DOM tree?

> 
> I'll change it if you feel really strongly about it, but I think for a demo
that
> isn't actually relying on polymer elements being fully registered, this
doesn't
> matter much.

I agree it doesn't matter much, if it's committed and it works. I thought it's
worth pointing out, since when I reviewed this initially I figured it would work
then too. Just trying to be thorough.

[dfreedm1, 2015-03-06 22:50:37]

That's a good question.

Each element has it's own version of "ready" as a callback (named
domReady), that is called when the subtree for that element is set up.
The "polymer-ready" event is fired when all element subtrees have reached
the "domReady" callback state.

@sorvell, are there any other spots they can use with 0.5 elements?



On Fri, Mar 6, 2015 at 2:33 PM, <michaelpg@chromium.org> wrote:

> @dfreedm, is this something you could help us with for future reference?
>
> We're not sure whether it's 1. necessary and 2. sufficient to wait for
> "polymer-ready" before setting properties on Polymer elements. I couldn't
> find a
> great answer in the Polymer docs, sorry if it's there somewhere.
>
> 1. Do we need to wait for the element to be upgraded before setting
> properties
> that are listed in the publish block?
>
> 2. Is the DOM itself guaranteed to be ready before "polymer-ready" is
> fired?
>
> Thanks!
>
>
> https://codereview.chromium.org/985533002/diff/180001/
> chrome/browser/resources/settings/a11y_page/demo.js
> File chrome/browser/resources/settings/a11y_page/demo.js (right):
>
> https://codereview.chromium.org/985533002/diff/180001/
> chrome/browser/resources/settings/a11y_page/demo.js#newcode8
> chrome/browser/resources/settings/a11y_page/demo.js:8: window.onload =
> function() {
> On 2015/03/06 21:33:56, Jeremy Klein wrote:
>
>> On 2015/03/06 20:25:59, michaelpg wrote:
>> > I believe it's more "correct" to use
>>
> window.addEventListener('polymer-ready',
>
>> > ...) to ensure the elements have been registered.
>>
>
>  This isn't really necessary in this case because the script here
>>
> doesn't depend
>
>> on any of the Polymer elements being upgraded, just that the DOM is
>>
> loaded.
>
> Data binding seems to work, but apparently it's not going through all
> the motions. If the element hasn't been upgraded, setting page.prefs
> just sets that property (which is all the page needs for data binding to
> start kicking in).
>
> Once the element has been upgraded, setting page.prefs would cause
> changed watchers to be called, updates page.prefs_, and whatever else
> Polymer does under the hood. If the attribute were reflected, the
> reflection wouldn't happen. So all of that doesn't happen if the element
> hasn't been upgraded yet. I don't know whether there's a guarantee in
> terms of what will work and what won't.
>
>  Also, do you know if polymer-ready is guaranteed to fire *after*
>>
> window.onload?
>
>> I know that it will probably almost always be true, but I'm not sure
>>
> there's a
>
>> guarantee there. If we got into a state where the polymer-ready fired
>>
> before
>
>> window.onload, we'd still hit errors in here.
>>
>
> I can't find that guarantee. But could polymer-ready be fired without
> the DOM? My understanding is it can only be fired once all
> polymer-element declarations have been executed. Can it ensure that
> before it's queried the entire DOM tree?
>
>
>  I'll change it if you feel really strongly about it, but I think for a
>>
> demo that
>
>> isn't actually relying on polymer elements being fully registered,
>>
> this doesn't
>
>> matter much.
>>
>
> I agree it doesn't matter much, if it's committed and it works. I
> thought it's worth pointing out, since when I reviewed this initially I
> figured it would work then too. Just trying to be thorough.
>
> https://codereview.chromium.org/985533002/revert
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2015-03-06 23:31:57]

`element.ready`: all the elements inside an element's shadowRoot are ready
so this is a good time to manipulate them, if necessary.

`element.domReady`: all the elements in the dom tree in which the element
exists that can upgrade have done so; it's safe to perform work on a parent
or child, for example.

`polymer-ready` event / `Polymer.whenReady`: all elements that have been
imported have been registered and as a consequence any existing elements
have been upgraded.



On Fri, Mar 6, 2015 at 2:50 PM, Daniel Freedman <dfreedm@chromium.org>
wrote:

> That's a good question.
>
> Each element has it's own version of "ready" as a callback (named
> domReady), that is called when the subtree for that element is set up.
> The "polymer-ready" event is fired when all element subtrees have reached
> the "domReady" callback state.
>
> @sorvell, are there any other spots they can use with 0.5 elements?
>
>
>
> On Fri, Mar 6, 2015 at 2:33 PM, <michaelpg@chromium.org> wrote:
>
>> @dfreedm, is this something you could help us with for future reference?
>>
>> We're not sure whether it's 1. necessary and 2. sufficient to wait for
>> "polymer-ready" before setting properties on Polymer elements. I couldn't
>> find a
>> great answer in the Polymer docs, sorry if it's there somewhere.
>>
>> 1. Do we need to wait for the element to be upgraded before setting
>> properties
>> that are listed in the publish block?
>>
>> 2. Is the DOM itself guaranteed to be ready before "polymer-ready" is
>> fired?
>>
>> Thanks!
>>
>>
>> https://codereview.chromium.org/985533002/diff/180001/
>> chrome/browser/resources/settings/a11y_page/demo.js
>> File chrome/browser/resources/settings/a11y_page/demo.js (right):
>>
>> https://codereview.chromium.org/985533002/diff/180001/
>> chrome/browser/resources/settings/a11y_page/demo.js#newcode8
>> chrome/browser/resources/settings/a11y_page/demo.js:8: window.onload =
>> function() {
>> On 2015/03/06 21:33:56, Jeremy Klein wrote:
>>
>>> On 2015/03/06 20:25:59, michaelpg wrote:
>>> > I believe it's more "correct" to use
>>>
>> window.addEventListener('polymer-ready',
>>
>>> > ...) to ensure the elements have been registered.
>>>
>>
>>  This isn't really necessary in this case because the script here
>>>
>> doesn't depend
>>
>>> on any of the Polymer elements being upgraded, just that the DOM is
>>>
>> loaded.
>>
>> Data binding seems to work, but apparently it's not going through all
>> the motions. If the element hasn't been upgraded, setting page.prefs
>> just sets that property (which is all the page needs for data binding to
>> start kicking in).
>>
>> Once the element has been upgraded, setting page.prefs would cause
>> changed watchers to be called, updates page.prefs_, and whatever else
>> Polymer does under the hood. If the attribute were reflected, the
>> reflection wouldn't happen. So all of that doesn't happen if the element
>> hasn't been upgraded yet. I don't know whether there's a guarantee in
>> terms of what will work and what won't.
>>
>>  Also, do you know if polymer-ready is guaranteed to fire *after*
>>>
>> window.onload?
>>
>>> I know that it will probably almost always be true, but I'm not sure
>>>
>> there's a
>>
>>> guarantee there. If we got into a state where the polymer-ready fired
>>>
>> before
>>
>>> window.onload, we'd still hit errors in here.
>>>
>>
>> I can't find that guarantee. But could polymer-ready be fired without
>> the DOM? My understanding is it can only be fired once all
>> polymer-element declarations have been executed. Can it ensure that
>> before it's queried the entire DOM tree?
>>
>>
>>  I'll change it if you feel really strongly about it, but I think for a
>>>
>> demo that
>>
>>> isn't actually relying on polymer elements being fully registered,
>>>
>> this doesn't
>>
>>> matter much.
>>>
>>
>> I agree it doesn't matter much, if it's committed and it works. I
>> thought it's worth pointing out, since when I reviewed this initially I
>> figured it would work then too. Just trying to be thorough.
>>
>> https://codereview.chromium.org/985533002/revert
>>
>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[michaelpg, 2015-03-08 05:55:41]

Thanks, Steve. Sorry my questions were a bit confusing.

My main question is: is it OK to update a published property on an element
before that element has been upgraded?

For instance, if myIcon represents a <core-icon> in the outermost document,
is it safe to do "myIcon.src = newSrc;" as soon as window.onload fires, and
expect the <core-icon>'s srcChanged to be called? Or should I wait for
polymer-ready to fire? Example script here. <http://pastebin.com/yt7zUamH>

The second, unrelated question was whether polymer-ready always fires after
window.onload, or if polymer-ready could fire before the whole DOM is ready.

Thanks,
Michael

On Fri, Mar 6, 2015 at 3:31 PM, Steve Orvell <sorvell@google.com> wrote:

> `element.ready`: all the elements inside an element's shadowRoot are ready
> so this is a good time to manipulate them, if necessary.
>
> `element.domReady`: all the elements in the dom tree in which the element
> exists that can upgrade have done so; it's safe to perform work on a parent
> or child, for example.
>
> `polymer-ready` event / `Polymer.whenReady`: all elements that have been
> imported have been registered and as a consequence any existing elements
> have been upgraded.
>
>
>
> On Fri, Mar 6, 2015 at 2:50 PM, Daniel Freedman <dfreedm@chromium.org>
> wrote:
>
>> That's a good question.
>>
>> Each element has it's own version of "ready" as a callback (named
>> domReady), that is called when the subtree for that element is set up.
>> The "polymer-ready" event is fired when all element subtrees have reached
>> the "domReady" callback state.
>>
>> @sorvell, are there any other spots they can use with 0.5 elements?
>>
>>
>>
>> On Fri, Mar 6, 2015 at 2:33 PM, <michaelpg@chromium.org> wrote:
>>
>>> @dfreedm, is this something you could help us with for future reference?
>>>
>>> We're not sure whether it's 1. necessary and 2. sufficient to wait for
>>> "polymer-ready" before setting properties on Polymer elements. I
>>> couldn't find a
>>> great answer in the Polymer docs, sorry if it's there somewhere.
>>>
>>> 1. Do we need to wait for the element to be upgraded before setting
>>> properties
>>> that are listed in the publish block?
>>>
>>> 2. Is the DOM itself guaranteed to be ready before "polymer-ready" is
>>> fired?
>>>
>>> Thanks!
>>>
>>>
>>> https://codereview.chromium.org/985533002/diff/180001/
>>> chrome/browser/resources/settings/a11y_page/demo.js
>>> File chrome/browser/resources/settings/a11y_page/demo.js (right):
>>>
>>> https://codereview.chromium.org/985533002/diff/180001/
>>> chrome/browser/resources/settings/a11y_page/demo.js#newcode8
>>> chrome/browser/resources/settings/a11y_page/demo.js:8: window.onload =
>>> function() {
>>> On 2015/03/06 21:33:56, Jeremy Klein wrote:
>>>
>>>> On 2015/03/06 20:25:59, michaelpg wrote:
>>>> > I believe it's more "correct" to use
>>>>
>>> window.addEventListener('polymer-ready',
>>>
>>>> > ...) to ensure the elements have been registered.
>>>>
>>>
>>>  This isn't really necessary in this case because the script here
>>>>
>>> doesn't depend
>>>
>>>> on any of the Polymer elements being upgraded, just that the DOM is
>>>>
>>> loaded.
>>>
>>> Data binding seems to work, but apparently it's not going through all
>>> the motions. If the element hasn't been upgraded, setting page.prefs
>>> just sets that property (which is all the page needs for data binding to
>>> start kicking in).
>>>
>>> Once the element has been upgraded, setting page.prefs would cause
>>> changed watchers to be called, updates page.prefs_, and whatever else
>>> Polymer does under the hood. If the attribute were reflected, the
>>> reflection wouldn't happen. So all of that doesn't happen if the element
>>> hasn't been upgraded yet. I don't know whether there's a guarantee in
>>> terms of what will work and what won't.
>>>
>>>  Also, do you know if polymer-ready is guaranteed to fire *after*
>>>>
>>> window.onload?
>>>
>>>> I know that it will probably almost always be true, but I'm not sure
>>>>
>>> there's a
>>>
>>>> guarantee there. If we got into a state where the polymer-ready fired
>>>>
>>> before
>>>
>>>> window.onload, we'd still hit errors in here.
>>>>
>>>
>>> I can't find that guarantee. But could polymer-ready be fired without
>>> the DOM? My understanding is it can only be fired once all
>>> polymer-element declarations have been executed. Can it ensure that
>>> before it's queried the entire DOM tree?
>>>
>>>
>>>  I'll change it if you feel really strongly about it, but I think for a
>>>>
>>> demo that
>>>
>>>> isn't actually relying on polymer elements being fully registered,
>>>>
>>> this doesn't
>>>
>>>> matter much.
>>>>
>>>
>>> I agree it doesn't matter much, if it's committed and it works. I
>>> thought it's worth pointing out, since when I reviewed this initially I
>>> figured it would work then too. Just trying to be thorough.
>>>
>>> https://codereview.chromium.org/985533002/revert
>>>
>>
>>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.