Remove internal option layout.autosize='initial' (Fixes #537)

[n-riesco]

• Moved initial call to plotAutoSize into Plots.supplyDefaults(gd).
• Replaced { autosize: 'initial' } with the flag
  gd._fullLayout._initialAutoSizeIsDone.
• { autosize: false } the values of width and height undefined in
  gd.layout will be autosized only once.
• { autosize: true } only autosizes the values of width and height
  undefined in gd.layout.

Fixes#537

[etpinard]

why do we need this?

[etpinard]

i.e. that if(typeof gd.emit === 'function')

[n-riesco]

Otherwise I get errors in the console (perhaps some test are mocking gd with something other than a DOM element?). I will come back to you on this tomorrow.

[etpinard]

Good call. Plots.supplyDefaults should work with plain objects.

Could we make this check more robust? I'd vote for using Lib.isPlotDiv.

[etpinard]

we should also check to svg attributes too to make sure that it updated properly.

[etpinard]

@n-riesco looks like you're on the right path.

Replaced { autosize: 'initial' } with the flag gd._fullLayout._initialAutoSizeIsDone

Yep. Great idea. 👍

{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't { autosize: false } lead to layout.width: 700 and layout.height: 400 as per their defaults?

{ autosize: true } only autosizes the values of width and height undefined in gd.layout

Great.

Unfortunately, the plotly.js auto-size routine has very poor test coverage; I'm a little concerned with merging this PR. @n-riesco could make sure that all code paths in plotAutoSize are tested under Plotly.plot and Plotly.relayout?

[n-riesco]

On 30/05/16 17:32, Étienne Tétreault-Pinard wrote:

@n-riescohttps://github.com/n-riesco looks like you're on the right path.
{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't |{ autosize: false }| lead to |layout.width: 700| and |layout.height: 400| as per their defaults?

The current behaviour is that if layout.width or layout.height are undefined, then layout.autosize is set to 'initial'.
When layout.autosize is set to 'initial' (and assuming config.fillFrame is false), plotAutosize gets the layout width and height using window.getComputedStyle(gd). Only if this fails, then the default width and height values are used.

Unfortunately, the plotly.js auto-size has very poor test coverage; I'm a little concerned with the PR. @n-riescohttps://github.com/n-riesco could make sure that all code paths in |plotAutoSize| https://github.com/plotly/plotly.js/pull/577/files#diff-ad4f76ccd6044ed16514297078e13b84R783 are tested under |Plotly.plot| and |Plotly.relayout|.

OK. I'll add more tests.

[alexcjohnson]

@n-riesco this is great, that's definitely where the autosize code belongs.

My only question (which goes along with @etpinard 's concern about test coverage - there are tons of cases to consider) is whether there are cases we'd like autosize to coerce to true - ie if width or height is missing? For example if someone is using element size to determine plot size, but has not explicitly set autosize: true - then something outside the plot (window resize or some event on their page) causes the element size to change, I would expect a simple redraw or relayout to resize the plot too.

This then begs the question (that we probably don't need to delve into now, might be a rabbit hole, but something to keep in mind for later) of whether we actually gain anything with the initial / redraw distinction. Either I'm missing something or it used to work differently, but I don't see that plotAutoSize does anything time-consuming, so what's to stop us from always running it if there's one or more missing dimensions or if autosize is explicitly true? There will be places (relayout?) where we need to track whether anything actually changed to decide how much to do next, but we already do that anyway.

[n-riesco]

Below are the tests I'm planning to add:

• autosize:false, fillFrame:true
• autosize:false, fillFrame:false and frameMargins
• autosize:false, fillFrame:false and no frameMargins
• autosize:true, fillFrame:true
• autosize:true, fillFrame:false and frameMargins
• autosize:true, fillFrame:false and no frameMargins

For each test, I'll check fullLayout width and height after plot and after relayout.

These tests should cover the main execution paths in plotAutoSize.

---

Additional tests (from comments):

• check SVG properties in test 'should respect layout.width and layout.height'
• test supplyDefaults(gd) can be called with mocked gd.

[etpinard]

@n-riesco your plans sounds good!

[n-riesco]

While writing the tests for this PR, I noticed that config accepts the attribute autosizable. In master, this attribute is only honoured by plotPolar. Its meaning in plotPolar is:

• if config.autosizable: false and layout.autosize: false, then no initial autosize is carried out (if needed, the default values of width and height are used);
• if config.autosizable: true, then an initial autosize is carried out (regardless of layout.autosize).

I've updated this PR so that autosizable is always honoured.

[n-riesco]

The PR is ready for review again.

[etpinard]

I think we should avoid using try-catch as much as possible - because they are very slow.

Here too, I'd vote for using Lib.isPlotDiv. But, I'm open to other (possible more strict) suggestions.

[n-riesco]

How about?

vargdBB=fullLayout._container&&fullLayout._container.node ?
fullLayout._container.node().getBoundingClientRect() : {width: fullLayout.width,height: fullLayout.height};

[n-riesco]

@etpinard About autosizable, I think it should be kept in Plotly v1, and removed in Plotly v2. The reason why I think it should be removed is that I don't think autosizable should be a global setting (different plots should be able to define different values of autosizable).

For Plotly v2, I would suggest to combine autosize and autosizable into a single setting. How about something like this?

{autosize: {valType: 'enumerated',role: 'info',values: ['never','initial','always'],description: ['Determines how a layout width or height','that has been left undefined by the user','is set.','If *never*, the default values of width and height will be used.','If *initial*, an undefined layout width or height','will be initialized on the first call to plot.''If *always*, an undefined layout width or height','will be set on the first call to plot and subsequent calls to relayout.'].join(' ')}}

[n-riesco]

PR ready for review again.

[etpinard]

Good. 👍

[etpinard]

Thanks @n-riesco . you're almost there.

As mentioned previously, this PR was set uncover a lot of un-tested code. Commits 172d81d and 862578e were no exceptions.

Would you mind a few test cases (one per commit is fine) for the two commits above? To lock their behavior until v2.0.0.

[n-riesco]

I've added tests for the commits you suggested and this uncovered an issue with 862578e and another with Lib.isPlotDiv. Both are now fixed and tested.

The PR is ready for review again.

[etpinard]

Great. I tested your branch and I couldn't find any edge cases that you might have missed. 🎉

This for sure wins the PR of the week 🏆

I'll make two minor comments on the line diff (nothing major) and then it'll be time to 💃 .

[etpinard]

we should change the valType to 'boolean' and remove the values field.

[etpinard]

@n-riesco , @chriddyp and I are testing the mapbox branch (which is rebased on top of the latest master) in the plot.ly workspace at the moment and we some issues.

Looks like this PR here is backward incompatible and the line ⏫ is a symptom.

More clearly,

Plotly.plot(gd,data);

should go through the plotAutoSize routine on the initial Plotly.plot call.

I believe changing the autosize attribute dflt to true would solve this. What are your thoughts on that?

[n-riesco]

@etpinard An alternative that would be fully backwards-compatible is that Plot.resize(gd) deletes gd.layout.width and gd.layout.height and calls Plotly.relayout(gd, { autosize: true });. I'll prepare a PR so that you can check that it'd fix the issue in the mapbox branch.

[n-riesco]

See #629

[etpinard]

As per-slack conversation with @n-riesco , I'm reverting this PR and will spend more time testing in plot.ly's workspace before the next minor release - to make sure we handle all edge cases in a backward-compatible way.

[n-riesco]

• Moved initial call to plotAutoSize into Plots.supplyDefaults(gd).
• Replaced { autosize: 'initial' } with the flag
  gd._fullLayout._initialAutoSizeIsDone.
• { autosize: false } the values of width and height undefined in
  gd.layout will be autosized only once.
• { autosize: true } only autosizes the values of width and height
  undefined in gd.layout.

Fixes#537

[etpinard]

why do we need this?

[etpinard]

i.e. that if(typeof gd.emit === 'function')

[n-riesco]

Otherwise I get errors in the console (perhaps some test are mocking gd with something other than a DOM element?). I will come back to you on this tomorrow.

[etpinard]

Good call. Plots.supplyDefaults should work with plain objects.

Could we make this check more robust? I'd vote for using Lib.isPlotDiv.

[etpinard]

we should also check to svg attributes too to make sure that it updated properly.

[etpinard]

@n-riesco looks like you're on the right path.

Replaced { autosize: 'initial' } with the flag gd._fullLayout._initialAutoSizeIsDone

Yep. Great idea. 👍

{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't { autosize: false } lead to layout.width: 700 and layout.height: 400 as per their defaults?

{ autosize: true } only autosizes the values of width and height undefined in gd.layout

Great.

Unfortunately, the plotly.js auto-size routine has very poor test coverage; I'm a little concerned with merging this PR. @n-riesco could make sure that all code paths in plotAutoSize are tested under Plotly.plot and Plotly.relayout?

[n-riesco]

On 30/05/16 17:32, Étienne Tétreault-Pinard wrote:

@n-riescohttps://github.com/n-riesco looks like you're on the right path.
{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't |{ autosize: false }| lead to |layout.width: 700| and |layout.height: 400| as per their defaults?

The current behaviour is that if layout.width or layout.height are undefined, then layout.autosize is set to 'initial'.
When layout.autosize is set to 'initial' (and assuming config.fillFrame is false), plotAutosize gets the layout width and height using window.getComputedStyle(gd). Only if this fails, then the default width and height values are used.

Unfortunately, the plotly.js auto-size has very poor test coverage; I'm a little concerned with the PR. @n-riescohttps://github.com/n-riesco could make sure that all code paths in |plotAutoSize| https://github.com/plotly/plotly.js/pull/577/files#diff-ad4f76ccd6044ed16514297078e13b84R783 are tested under |Plotly.plot| and |Plotly.relayout|.

OK. I'll add more tests.

[alexcjohnson]

@n-riesco this is great, that's definitely where the autosize code belongs.

My only question (which goes along with @etpinard 's concern about test coverage - there are tons of cases to consider) is whether there are cases we'd like autosize to coerce to true - ie if width or height is missing? For example if someone is using element size to determine plot size, but has not explicitly set autosize: true - then something outside the plot (window resize or some event on their page) causes the element size to change, I would expect a simple redraw or relayout to resize the plot too.

This then begs the question (that we probably don't need to delve into now, might be a rabbit hole, but something to keep in mind for later) of whether we actually gain anything with the initial / redraw distinction. Either I'm missing something or it used to work differently, but I don't see that plotAutoSize does anything time-consuming, so what's to stop us from always running it if there's one or more missing dimensions or if autosize is explicitly true? There will be places (relayout?) where we need to track whether anything actually changed to decide how much to do next, but we already do that anyway.

[n-riesco]

Below are the tests I'm planning to add:

• autosize:false, fillFrame:true
• autosize:false, fillFrame:false and frameMargins
• autosize:false, fillFrame:false and no frameMargins
• autosize:true, fillFrame:true
• autosize:true, fillFrame:false and frameMargins
• autosize:true, fillFrame:false and no frameMargins

For each test, I'll check fullLayout width and height after plot and after relayout.

These tests should cover the main execution paths in plotAutoSize.

---

Additional tests (from comments):

• check SVG properties in test 'should respect layout.width and layout.height'
• test supplyDefaults(gd) can be called with mocked gd.

[etpinard]

@n-riesco your plans sounds good!

[n-riesco]

While writing the tests for this PR, I noticed that config accepts the attribute autosizable. In master, this attribute is only honoured by plotPolar. Its meaning in plotPolar is:

• if config.autosizable: false and layout.autosize: false, then no initial autosize is carried out (if needed, the default values of width and height are used);
• if config.autosizable: true, then an initial autosize is carried out (regardless of layout.autosize).

I've updated this PR so that autosizable is always honoured.

[n-riesco]

The PR is ready for review again.

[etpinard]

I think we should avoid using try-catch as much as possible - because they are very slow.

Here too, I'd vote for using Lib.isPlotDiv. But, I'm open to other (possible more strict) suggestions.

[n-riesco]

How about?

vargdBB=fullLayout._container&&fullLayout._container.node ?
fullLayout._container.node().getBoundingClientRect() : {width: fullLayout.width,height: fullLayout.height};

[n-riesco]

@etpinard About autosizable, I think it should be kept in Plotly v1, and removed in Plotly v2. The reason why I think it should be removed is that I don't think autosizable should be a global setting (different plots should be able to define different values of autosizable).

For Plotly v2, I would suggest to combine autosize and autosizable into a single setting. How about something like this?

{autosize: {valType: 'enumerated',role: 'info',values: ['never','initial','always'],description: ['Determines how a layout width or height','that has been left undefined by the user','is set.','If *never*, the default values of width and height will be used.','If *initial*, an undefined layout width or height','will be initialized on the first call to plot.''If *always*, an undefined layout width or height','will be set on the first call to plot and subsequent calls to relayout.'].join(' ')}}

[n-riesco]

PR ready for review again.

[etpinard]

Good. 👍

[etpinard]

Thanks @n-riesco . you're almost there.

As mentioned previously, this PR was set uncover a lot of un-tested code. Commits 172d81d and 862578e were no exceptions.

Would you mind a few test cases (one per commit is fine) for the two commits above? To lock their behavior until v2.0.0.

[n-riesco]

I've added tests for the commits you suggested and this uncovered an issue with 862578e and another with Lib.isPlotDiv. Both are now fixed and tested.

The PR is ready for review again.

[etpinard]

Great. I tested your branch and I couldn't find any edge cases that you might have missed. 🎉

This for sure wins the PR of the week 🏆

I'll make two minor comments on the line diff (nothing major) and then it'll be time to 💃 .

[etpinard]

we should change the valType to 'boolean' and remove the values field.

[etpinard]

@n-riesco , @chriddyp and I are testing the mapbox branch (which is rebased on top of the latest master) in the plot.ly workspace at the moment and we some issues.

Looks like this PR here is backward incompatible and the line ⏫ is a symptom.

More clearly,

Plotly.plot(gd,data);

should go through the plotAutoSize routine on the initial Plotly.plot call.

I believe changing the autosize attribute dflt to true would solve this. What are your thoughts on that?

[n-riesco]

@etpinard An alternative that would be fully backwards-compatible is that Plot.resize(gd) deletes gd.layout.width and gd.layout.height and calls Plotly.relayout(gd, { autosize: true });. I'll prepare a PR so that you can check that it'd fix the issue in the mapbox branch.

[n-riesco]

See #629

[etpinard]

As per-slack conversation with @n-riesco , I'm reverting this PR and will spend more time testing in plot.ly's workspace before the next minor release - to make sure we handle all edge cases in a backward-compatible way.

[n-riesco]

• Moved initial call to plotAutoSize into Plots.supplyDefaults(gd).
• Replaced { autosize: 'initial' } with the flag
  gd._fullLayout._initialAutoSizeIsDone.
• { autosize: false } the values of width and height undefined in
  gd.layout will be autosized only once.
• { autosize: true } only autosizes the values of width and height
  undefined in gd.layout.

Fixes#537

[etpinard]

why do we need this?

[etpinard]

i.e. that if(typeof gd.emit === 'function')

[n-riesco]

Otherwise I get errors in the console (perhaps some test are mocking gd with something other than a DOM element?). I will come back to you on this tomorrow.

[etpinard]

Good call. Plots.supplyDefaults should work with plain objects.

Could we make this check more robust? I'd vote for using Lib.isPlotDiv.

[etpinard]

we should also check to svg attributes too to make sure that it updated properly.

[etpinard]

@n-riesco looks like you're on the right path.

Replaced { autosize: 'initial' } with the flag gd._fullLayout._initialAutoSizeIsDone

Yep. Great idea. 👍

{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't { autosize: false } lead to layout.width: 700 and layout.height: 400 as per their defaults?

{ autosize: true } only autosizes the values of width and height undefined in gd.layout

Great.

Unfortunately, the plotly.js auto-size routine has very poor test coverage; I'm a little concerned with merging this PR. @n-riesco could make sure that all code paths in plotAutoSize are tested under Plotly.plot and Plotly.relayout?

[n-riesco]

On 30/05/16 17:32, Étienne Tétreault-Pinard wrote:

@n-riescohttps://github.com/n-riesco looks like you're on the right path.
{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't |{ autosize: false }| lead to |layout.width: 700| and |layout.height: 400| as per their defaults?

The current behaviour is that if layout.width or layout.height are undefined, then layout.autosize is set to 'initial'.
When layout.autosize is set to 'initial' (and assuming config.fillFrame is false), plotAutosize gets the layout width and height using window.getComputedStyle(gd). Only if this fails, then the default width and height values are used.

Unfortunately, the plotly.js auto-size has very poor test coverage; I'm a little concerned with the PR. @n-riescohttps://github.com/n-riesco could make sure that all code paths in |plotAutoSize| https://github.com/plotly/plotly.js/pull/577/files#diff-ad4f76ccd6044ed16514297078e13b84R783 are tested under |Plotly.plot| and |Plotly.relayout|.

OK. I'll add more tests.

[alexcjohnson]

@n-riesco this is great, that's definitely where the autosize code belongs.

My only question (which goes along with @etpinard 's concern about test coverage - there are tons of cases to consider) is whether there are cases we'd like autosize to coerce to true - ie if width or height is missing? For example if someone is using element size to determine plot size, but has not explicitly set autosize: true - then something outside the plot (window resize or some event on their page) causes the element size to change, I would expect a simple redraw or relayout to resize the plot too.

This then begs the question (that we probably don't need to delve into now, might be a rabbit hole, but something to keep in mind for later) of whether we actually gain anything with the initial / redraw distinction. Either I'm missing something or it used to work differently, but I don't see that plotAutoSize does anything time-consuming, so what's to stop us from always running it if there's one or more missing dimensions or if autosize is explicitly true? There will be places (relayout?) where we need to track whether anything actually changed to decide how much to do next, but we already do that anyway.

[n-riesco]

Below are the tests I'm planning to add:

• autosize:false, fillFrame:true
• autosize:false, fillFrame:false and frameMargins
• autosize:false, fillFrame:false and no frameMargins
• autosize:true, fillFrame:true
• autosize:true, fillFrame:false and frameMargins
• autosize:true, fillFrame:false and no frameMargins

For each test, I'll check fullLayout width and height after plot and after relayout.

These tests should cover the main execution paths in plotAutoSize.

---

Additional tests (from comments):

• check SVG properties in test 'should respect layout.width and layout.height'
• test supplyDefaults(gd) can be called with mocked gd.

[etpinard]

@n-riesco your plans sounds good!

[n-riesco]

While writing the tests for this PR, I noticed that config accepts the attribute autosizable. In master, this attribute is only honoured by plotPolar. Its meaning in plotPolar is:

• if config.autosizable: false and layout.autosize: false, then no initial autosize is carried out (if needed, the default values of width and height are used);
• if config.autosizable: true, then an initial autosize is carried out (regardless of layout.autosize).

I've updated this PR so that autosizable is always honoured.

[n-riesco]

The PR is ready for review again.

[etpinard]

I think we should avoid using try-catch as much as possible - because they are very slow.

Here too, I'd vote for using Lib.isPlotDiv. But, I'm open to other (possible more strict) suggestions.

[n-riesco]

How about?

vargdBB=fullLayout._container&&fullLayout._container.node ?
fullLayout._container.node().getBoundingClientRect() : {width: fullLayout.width,height: fullLayout.height};

[n-riesco]

@etpinard About autosizable, I think it should be kept in Plotly v1, and removed in Plotly v2. The reason why I think it should be removed is that I don't think autosizable should be a global setting (different plots should be able to define different values of autosizable).

For Plotly v2, I would suggest to combine autosize and autosizable into a single setting. How about something like this?

{autosize: {valType: 'enumerated',role: 'info',values: ['never','initial','always'],description: ['Determines how a layout width or height','that has been left undefined by the user','is set.','If *never*, the default values of width and height will be used.','If *initial*, an undefined layout width or height','will be initialized on the first call to plot.''If *always*, an undefined layout width or height','will be set on the first call to plot and subsequent calls to relayout.'].join(' ')}}

[n-riesco]

PR ready for review again.

[etpinard]

Good. 👍

[etpinard]

Thanks @n-riesco . you're almost there.

As mentioned previously, this PR was set uncover a lot of un-tested code. Commits 172d81d and 862578e were no exceptions.

Would you mind a few test cases (one per commit is fine) for the two commits above? To lock their behavior until v2.0.0.

[n-riesco]

I've added tests for the commits you suggested and this uncovered an issue with 862578e and another with Lib.isPlotDiv. Both are now fixed and tested.

The PR is ready for review again.

[etpinard]

Great. I tested your branch and I couldn't find any edge cases that you might have missed. 🎉

This for sure wins the PR of the week 🏆

I'll make two minor comments on the line diff (nothing major) and then it'll be time to 💃 .

[etpinard]

we should change the valType to 'boolean' and remove the values field.

[etpinard]

@n-riesco , @chriddyp and I are testing the mapbox branch (which is rebased on top of the latest master) in the plot.ly workspace at the moment and we some issues.

Looks like this PR here is backward incompatible and the line ⏫ is a symptom.

More clearly,

Plotly.plot(gd,data);

should go through the plotAutoSize routine on the initial Plotly.plot call.

I believe changing the autosize attribute dflt to true would solve this. What are your thoughts on that?

[n-riesco]

@etpinard An alternative that would be fully backwards-compatible is that Plot.resize(gd) deletes gd.layout.width and gd.layout.height and calls Plotly.relayout(gd, { autosize: true });. I'll prepare a PR so that you can check that it'd fix the issue in the mapbox branch.

[n-riesco]

See #629

[etpinard]

As per-slack conversation with @n-riesco , I'm reverting this PR and will spend more time testing in plot.ly's workspace before the next minor release - to make sure we handle all edge cases in a backward-compatible way.

[n-riesco]

• Moved initial call to plotAutoSize into Plots.supplyDefaults(gd).
• Replaced { autosize: 'initial' } with the flag
  gd._fullLayout._initialAutoSizeIsDone.
• { autosize: false } the values of width and height undefined in
  gd.layout will be autosized only once.
• { autosize: true } only autosizes the values of width and height
  undefined in gd.layout.

Fixes#537

[etpinard]

why do we need this?

[etpinard]

i.e. that if(typeof gd.emit === 'function')

[n-riesco]

Otherwise I get errors in the console (perhaps some test are mocking gd with something other than a DOM element?). I will come back to you on this tomorrow.

[etpinard]

Good call. Plots.supplyDefaults should work with plain objects.

Could we make this check more robust? I'd vote for using Lib.isPlotDiv.

[etpinard]

we should also check to svg attributes too to make sure that it updated properly.

[etpinard]

@n-riesco looks like you're on the right path.

Replaced { autosize: 'initial' } with the flag gd._fullLayout._initialAutoSizeIsDone

Yep. Great idea. 👍

{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't { autosize: false } lead to layout.width: 700 and layout.height: 400 as per their defaults?

{ autosize: true } only autosizes the values of width and height undefined in gd.layout

Great.

Unfortunately, the plotly.js auto-size routine has very poor test coverage; I'm a little concerned with merging this PR. @n-riesco could make sure that all code paths in plotAutoSize are tested under Plotly.plot and Plotly.relayout?

[n-riesco]

On 30/05/16 17:32, Étienne Tétreault-Pinard wrote:

@n-riescohttps://github.com/n-riesco looks like you're on the right path.
{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't |{ autosize: false }| lead to |layout.width: 700| and |layout.height: 400| as per their defaults?

The current behaviour is that if layout.width or layout.height are undefined, then layout.autosize is set to 'initial'.
When layout.autosize is set to 'initial' (and assuming config.fillFrame is false), plotAutosize gets the layout width and height using window.getComputedStyle(gd). Only if this fails, then the default width and height values are used.

Unfortunately, the plotly.js auto-size has very poor test coverage; I'm a little concerned with the PR. @n-riescohttps://github.com/n-riesco could make sure that all code paths in |plotAutoSize| https://github.com/plotly/plotly.js/pull/577/files#diff-ad4f76ccd6044ed16514297078e13b84R783 are tested under |Plotly.plot| and |Plotly.relayout|.

OK. I'll add more tests.

[alexcjohnson]

@n-riesco this is great, that's definitely where the autosize code belongs.

My only question (which goes along with @etpinard 's concern about test coverage - there are tons of cases to consider) is whether there are cases we'd like autosize to coerce to true - ie if width or height is missing? For example if someone is using element size to determine plot size, but has not explicitly set autosize: true - then something outside the plot (window resize or some event on their page) causes the element size to change, I would expect a simple redraw or relayout to resize the plot too.

This then begs the question (that we probably don't need to delve into now, might be a rabbit hole, but something to keep in mind for later) of whether we actually gain anything with the initial / redraw distinction. Either I'm missing something or it used to work differently, but I don't see that plotAutoSize does anything time-consuming, so what's to stop us from always running it if there's one or more missing dimensions or if autosize is explicitly true? There will be places (relayout?) where we need to track whether anything actually changed to decide how much to do next, but we already do that anyway.

[n-riesco]

Below are the tests I'm planning to add:

• autosize:false, fillFrame:true
• autosize:false, fillFrame:false and frameMargins
• autosize:false, fillFrame:false and no frameMargins
• autosize:true, fillFrame:true
• autosize:true, fillFrame:false and frameMargins
• autosize:true, fillFrame:false and no frameMargins

For each test, I'll check fullLayout width and height after plot and after relayout.

These tests should cover the main execution paths in plotAutoSize.

---

Additional tests (from comments):

• check SVG properties in test 'should respect layout.width and layout.height'
• test supplyDefaults(gd) can be called with mocked gd.

[etpinard]

@n-riesco your plans sounds good!

[n-riesco]

While writing the tests for this PR, I noticed that config accepts the attribute autosizable. In master, this attribute is only honoured by plotPolar. Its meaning in plotPolar is:

• if config.autosizable: false and layout.autosize: false, then no initial autosize is carried out (if needed, the default values of width and height are used);
• if config.autosizable: true, then an initial autosize is carried out (regardless of layout.autosize).

I've updated this PR so that autosizable is always honoured.

[n-riesco]

The PR is ready for review again.

[etpinard]

I think we should avoid using try-catch as much as possible - because they are very slow.

Here too, I'd vote for using Lib.isPlotDiv. But, I'm open to other (possible more strict) suggestions.

[n-riesco]

How about?

vargdBB=fullLayout._container&&fullLayout._container.node ?
fullLayout._container.node().getBoundingClientRect() : {width: fullLayout.width,height: fullLayout.height};

[n-riesco]

@etpinard About autosizable, I think it should be kept in Plotly v1, and removed in Plotly v2. The reason why I think it should be removed is that I don't think autosizable should be a global setting (different plots should be able to define different values of autosizable).

For Plotly v2, I would suggest to combine autosize and autosizable into a single setting. How about something like this?

{autosize: {valType: 'enumerated',role: 'info',values: ['never','initial','always'],description: ['Determines how a layout width or height','that has been left undefined by the user','is set.','If *never*, the default values of width and height will be used.','If *initial*, an undefined layout width or height','will be initialized on the first call to plot.''If *always*, an undefined layout width or height','will be set on the first call to plot and subsequent calls to relayout.'].join(' ')}}

[n-riesco]

PR ready for review again.

[etpinard]

Good. 👍

[etpinard]

Thanks @n-riesco . you're almost there.

As mentioned previously, this PR was set uncover a lot of un-tested code. Commits 172d81d and 862578e were no exceptions.

Would you mind a few test cases (one per commit is fine) for the two commits above? To lock their behavior until v2.0.0.

[n-riesco]

I've added tests for the commits you suggested and this uncovered an issue with 862578e and another with Lib.isPlotDiv. Both are now fixed and tested.

The PR is ready for review again.

[etpinard]

Great. I tested your branch and I couldn't find any edge cases that you might have missed. 🎉

This for sure wins the PR of the week 🏆

I'll make two minor comments on the line diff (nothing major) and then it'll be time to 💃 .

[etpinard]

we should change the valType to 'boolean' and remove the values field.

[etpinard]

@n-riesco , @chriddyp and I are testing the mapbox branch (which is rebased on top of the latest master) in the plot.ly workspace at the moment and we some issues.

Looks like this PR here is backward incompatible and the line ⏫ is a symptom.

More clearly,

Plotly.plot(gd,data);

should go through the plotAutoSize routine on the initial Plotly.plot call.

I believe changing the autosize attribute dflt to true would solve this. What are your thoughts on that?

[n-riesco]

@etpinard An alternative that would be fully backwards-compatible is that Plot.resize(gd) deletes gd.layout.width and gd.layout.height and calls Plotly.relayout(gd, { autosize: true });. I'll prepare a PR so that you can check that it'd fix the issue in the mapbox branch.

[n-riesco]

See #629

[etpinard]

As per-slack conversation with @n-riesco , I'm reverting this PR and will spend more time testing in plot.ly's workspace before the next minor release - to make sure we handle all edge cases in a backward-compatible way.

[n-riesco]

• Moved initial call to plotAutoSize into Plots.supplyDefaults(gd).
• Replaced { autosize: 'initial' } with the flag
  gd._fullLayout._initialAutoSizeIsDone.
• { autosize: false } the values of width and height undefined in
  gd.layout will be autosized only once.
• { autosize: true } only autosizes the values of width and height
  undefined in gd.layout.

Fixes#537

[etpinard]

why do we need this?

[etpinard]

i.e. that if(typeof gd.emit === 'function')

[n-riesco]

Otherwise I get errors in the console (perhaps some test are mocking gd with something other than a DOM element?). I will come back to you on this tomorrow.

[etpinard]

Good call. Plots.supplyDefaults should work with plain objects.

Could we make this check more robust? I'd vote for using Lib.isPlotDiv.

[etpinard]

we should also check to svg attributes too to make sure that it updated properly.

[etpinard]

@n-riesco looks like you're on the right path.

Replaced { autosize: 'initial' } with the flag gd._fullLayout._initialAutoSizeIsDone

Yep. Great idea. 👍

{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't { autosize: false } lead to layout.width: 700 and layout.height: 400 as per their defaults?

{ autosize: true } only autosizes the values of width and height undefined in gd.layout

Great.

Unfortunately, the plotly.js auto-size routine has very poor test coverage; I'm a little concerned with merging this PR. @n-riesco could make sure that all code paths in plotAutoSize are tested under Plotly.plot and Plotly.relayout?

[n-riesco]

On 30/05/16 17:32, Étienne Tétreault-Pinard wrote:

@n-riescohttps://github.com/n-riesco looks like you're on the right path.
{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't |{ autosize: false }| lead to |layout.width: 700| and |layout.height: 400| as per their defaults?

The current behaviour is that if layout.width or layout.height are undefined, then layout.autosize is set to 'initial'.
When layout.autosize is set to 'initial' (and assuming config.fillFrame is false), plotAutosize gets the layout width and height using window.getComputedStyle(gd). Only if this fails, then the default width and height values are used.

Unfortunately, the plotly.js auto-size has very poor test coverage; I'm a little concerned with the PR. @n-riescohttps://github.com/n-riesco could make sure that all code paths in |plotAutoSize| https://github.com/plotly/plotly.js/pull/577/files#diff-ad4f76ccd6044ed16514297078e13b84R783 are tested under |Plotly.plot| and |Plotly.relayout|.

OK. I'll add more tests.

[alexcjohnson]

@n-riesco this is great, that's definitely where the autosize code belongs.

My only question (which goes along with @etpinard 's concern about test coverage - there are tons of cases to consider) is whether there are cases we'd like autosize to coerce to true - ie if width or height is missing? For example if someone is using element size to determine plot size, but has not explicitly set autosize: true - then something outside the plot (window resize or some event on their page) causes the element size to change, I would expect a simple redraw or relayout to resize the plot too.

This then begs the question (that we probably don't need to delve into now, might be a rabbit hole, but something to keep in mind for later) of whether we actually gain anything with the initial / redraw distinction. Either I'm missing something or it used to work differently, but I don't see that plotAutoSize does anything time-consuming, so what's to stop us from always running it if there's one or more missing dimensions or if autosize is explicitly true? There will be places (relayout?) where we need to track whether anything actually changed to decide how much to do next, but we already do that anyway.

[n-riesco]

Below are the tests I'm planning to add:

• autosize:false, fillFrame:true
• autosize:false, fillFrame:false and frameMargins
• autosize:false, fillFrame:false and no frameMargins
• autosize:true, fillFrame:true
• autosize:true, fillFrame:false and frameMargins
• autosize:true, fillFrame:false and no frameMargins

For each test, I'll check fullLayout width and height after plot and after relayout.

These tests should cover the main execution paths in plotAutoSize.

---

Additional tests (from comments):

• check SVG properties in test 'should respect layout.width and layout.height'
• test supplyDefaults(gd) can be called with mocked gd.

[etpinard]

@n-riesco your plans sounds good!

[n-riesco]

While writing the tests for this PR, I noticed that config accepts the attribute autosizable. In master, this attribute is only honoured by plotPolar. Its meaning in plotPolar is:

• if config.autosizable: false and layout.autosize: false, then no initial autosize is carried out (if needed, the default values of width and height are used);
• if config.autosizable: true, then an initial autosize is carried out (regardless of layout.autosize).

I've updated this PR so that autosizable is always honoured.

[n-riesco]

The PR is ready for review again.

[etpinard]

I think we should avoid using try-catch as much as possible - because they are very slow.

Here too, I'd vote for using Lib.isPlotDiv. But, I'm open to other (possible more strict) suggestions.

[n-riesco]

How about?

vargdBB=fullLayout._container&&fullLayout._container.node ?
fullLayout._container.node().getBoundingClientRect() : {width: fullLayout.width,height: fullLayout.height};

[n-riesco]

@etpinard About autosizable, I think it should be kept in Plotly v1, and removed in Plotly v2. The reason why I think it should be removed is that I don't think autosizable should be a global setting (different plots should be able to define different values of autosizable).

For Plotly v2, I would suggest to combine autosize and autosizable into a single setting. How about something like this?

{autosize: {valType: 'enumerated',role: 'info',values: ['never','initial','always'],description: ['Determines how a layout width or height','that has been left undefined by the user','is set.','If *never*, the default values of width and height will be used.','If *initial*, an undefined layout width or height','will be initialized on the first call to plot.''If *always*, an undefined layout width or height','will be set on the first call to plot and subsequent calls to relayout.'].join(' ')}}

[n-riesco]

PR ready for review again.

[etpinard]

Good. 👍

[etpinard]

Thanks @n-riesco . you're almost there.

As mentioned previously, this PR was set uncover a lot of un-tested code. Commits 172d81d and 862578e were no exceptions.

Would you mind a few test cases (one per commit is fine) for the two commits above? To lock their behavior until v2.0.0.

[n-riesco]

I've added tests for the commits you suggested and this uncovered an issue with 862578e and another with Lib.isPlotDiv. Both are now fixed and tested.

The PR is ready for review again.

[etpinard]

Great. I tested your branch and I couldn't find any edge cases that you might have missed. 🎉

This for sure wins the PR of the week 🏆

I'll make two minor comments on the line diff (nothing major) and then it'll be time to 💃 .

[etpinard]

we should change the valType to 'boolean' and remove the values field.

[etpinard]

@n-riesco , @chriddyp and I are testing the mapbox branch (which is rebased on top of the latest master) in the plot.ly workspace at the moment and we some issues.

Looks like this PR here is backward incompatible and the line ⏫ is a symptom.

More clearly,

Plotly.plot(gd,data);

should go through the plotAutoSize routine on the initial Plotly.plot call.

I believe changing the autosize attribute dflt to true would solve this. What are your thoughts on that?

[n-riesco]

@etpinard An alternative that would be fully backwards-compatible is that Plot.resize(gd) deletes gd.layout.width and gd.layout.height and calls Plotly.relayout(gd, { autosize: true });. I'll prepare a PR so that you can check that it'd fix the issue in the mapbox branch.

[n-riesco]

See #629

[etpinard]

As per-slack conversation with @n-riesco , I'm reverting this PR and will spend more time testing in plot.ly's workspace before the next minor release - to make sure we handle all edge cases in a backward-compatible way.

[n-riesco]

• Moved initial call to plotAutoSize into Plots.supplyDefaults(gd).
• Replaced { autosize: 'initial' } with the flag
  gd._fullLayout._initialAutoSizeIsDone.
• { autosize: false } the values of width and height undefined in
  gd.layout will be autosized only once.
• { autosize: true } only autosizes the values of width and height
  undefined in gd.layout.

Fixes#537

[etpinard]

why do we need this?

[etpinard]

i.e. that if(typeof gd.emit === 'function')

[n-riesco]

Otherwise I get errors in the console (perhaps some test are mocking gd with something other than a DOM element?). I will come back to you on this tomorrow.

[etpinard]

Good call. Plots.supplyDefaults should work with plain objects.

Could we make this check more robust? I'd vote for using Lib.isPlotDiv.

[etpinard]

we should also check to svg attributes too to make sure that it updated properly.

[etpinard]

@n-riesco looks like you're on the right path.

Replaced { autosize: 'initial' } with the flag gd._fullLayout._initialAutoSizeIsDone

Yep. Great idea. 👍

{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't { autosize: false } lead to layout.width: 700 and layout.height: 400 as per their defaults?

{ autosize: true } only autosizes the values of width and height undefined in gd.layout

Great.

Unfortunately, the plotly.js auto-size routine has very poor test coverage; I'm a little concerned with merging this PR. @n-riesco could make sure that all code paths in plotAutoSize are tested under Plotly.plot and Plotly.relayout?

[n-riesco]

On 30/05/16 17:32, Étienne Tétreault-Pinard wrote:

@n-riescohttps://github.com/n-riesco looks like you're on the right path.
{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't |{ autosize: false }| lead to |layout.width: 700| and |layout.height: 400| as per their defaults?

The current behaviour is that if layout.width or layout.height are undefined, then layout.autosize is set to 'initial'.
When layout.autosize is set to 'initial' (and assuming config.fillFrame is false), plotAutosize gets the layout width and height using window.getComputedStyle(gd). Only if this fails, then the default width and height values are used.

Unfortunately, the plotly.js auto-size has very poor test coverage; I'm a little concerned with the PR. @n-riescohttps://github.com/n-riesco could make sure that all code paths in |plotAutoSize| https://github.com/plotly/plotly.js/pull/577/files#diff-ad4f76ccd6044ed16514297078e13b84R783 are tested under |Plotly.plot| and |Plotly.relayout|.

OK. I'll add more tests.

[alexcjohnson]

@n-riesco this is great, that's definitely where the autosize code belongs.

My only question (which goes along with @etpinard 's concern about test coverage - there are tons of cases to consider) is whether there are cases we'd like autosize to coerce to true - ie if width or height is missing? For example if someone is using element size to determine plot size, but has not explicitly set autosize: true - then something outside the plot (window resize or some event on their page) causes the element size to change, I would expect a simple redraw or relayout to resize the plot too.

This then begs the question (that we probably don't need to delve into now, might be a rabbit hole, but something to keep in mind for later) of whether we actually gain anything with the initial / redraw distinction. Either I'm missing something or it used to work differently, but I don't see that plotAutoSize does anything time-consuming, so what's to stop us from always running it if there's one or more missing dimensions or if autosize is explicitly true? There will be places (relayout?) where we need to track whether anything actually changed to decide how much to do next, but we already do that anyway.

[n-riesco]

Below are the tests I'm planning to add:

• autosize:false, fillFrame:true
• autosize:false, fillFrame:false and frameMargins
• autosize:false, fillFrame:false and no frameMargins
• autosize:true, fillFrame:true
• autosize:true, fillFrame:false and frameMargins
• autosize:true, fillFrame:false and no frameMargins

For each test, I'll check fullLayout width and height after plot and after relayout.

These tests should cover the main execution paths in plotAutoSize.

---

Additional tests (from comments):

• check SVG properties in test 'should respect layout.width and layout.height'
• test supplyDefaults(gd) can be called with mocked gd.

[etpinard]

@n-riesco your plans sounds good!

[n-riesco]

While writing the tests for this PR, I noticed that config accepts the attribute autosizable. In master, this attribute is only honoured by plotPolar. Its meaning in plotPolar is:

• if config.autosizable: false and layout.autosize: false, then no initial autosize is carried out (if needed, the default values of width and height are used);
• if config.autosizable: true, then an initial autosize is carried out (regardless of layout.autosize).

I've updated this PR so that autosizable is always honoured.

[n-riesco]

The PR is ready for review again.

[etpinard]

I think we should avoid using try-catch as much as possible - because they are very slow.

Here too, I'd vote for using Lib.isPlotDiv. But, I'm open to other (possible more strict) suggestions.

[n-riesco]

How about?

vargdBB=fullLayout._container&&fullLayout._container.node ?
fullLayout._container.node().getBoundingClientRect() : {width: fullLayout.width,height: fullLayout.height};

[n-riesco]

@etpinard About autosizable, I think it should be kept in Plotly v1, and removed in Plotly v2. The reason why I think it should be removed is that I don't think autosizable should be a global setting (different plots should be able to define different values of autosizable).

For Plotly v2, I would suggest to combine autosize and autosizable into a single setting. How about something like this?

{autosize: {valType: 'enumerated',role: 'info',values: ['never','initial','always'],description: ['Determines how a layout width or height','that has been left undefined by the user','is set.','If *never*, the default values of width and height will be used.','If *initial*, an undefined layout width or height','will be initialized on the first call to plot.''If *always*, an undefined layout width or height','will be set on the first call to plot and subsequent calls to relayout.'].join(' ')}}

[n-riesco]

PR ready for review again.

[etpinard]

Good. 👍

[etpinard]

Thanks @n-riesco . you're almost there.

As mentioned previously, this PR was set uncover a lot of un-tested code. Commits 172d81d and 862578e were no exceptions.

Would you mind a few test cases (one per commit is fine) for the two commits above? To lock their behavior until v2.0.0.

[n-riesco]

I've added tests for the commits you suggested and this uncovered an issue with 862578e and another with Lib.isPlotDiv. Both are now fixed and tested.

The PR is ready for review again.

[etpinard]

Great. I tested your branch and I couldn't find any edge cases that you might have missed. 🎉

This for sure wins the PR of the week 🏆

I'll make two minor comments on the line diff (nothing major) and then it'll be time to 💃 .

[etpinard]

we should change the valType to 'boolean' and remove the values field.

[etpinard]

@n-riesco , @chriddyp and I are testing the mapbox branch (which is rebased on top of the latest master) in the plot.ly workspace at the moment and we some issues.

Looks like this PR here is backward incompatible and the line ⏫ is a symptom.

More clearly,

Plotly.plot(gd,data);

should go through the plotAutoSize routine on the initial Plotly.plot call.

I believe changing the autosize attribute dflt to true would solve this. What are your thoughts on that?

[n-riesco]

@etpinard An alternative that would be fully backwards-compatible is that Plot.resize(gd) deletes gd.layout.width and gd.layout.height and calls Plotly.relayout(gd, { autosize: true });. I'll prepare a PR so that you can check that it'd fix the issue in the mapbox branch.

[n-riesco]

See #629

[etpinard]

As per-slack conversation with @n-riesco , I'm reverting this PR and will spend more time testing in plot.ly's workspace before the next minor release - to make sure we handle all edge cases in a backward-compatible way.

[n-riesco]

• Moved initial call to plotAutoSize into Plots.supplyDefaults(gd).
• Replaced { autosize: 'initial' } with the flag
  gd._fullLayout._initialAutoSizeIsDone.
• { autosize: false } the values of width and height undefined in
  gd.layout will be autosized only once.
• { autosize: true } only autosizes the values of width and height
  undefined in gd.layout.

Fixes#537

[etpinard]

why do we need this?

[etpinard]

i.e. that if(typeof gd.emit === 'function')

[n-riesco]

Otherwise I get errors in the console (perhaps some test are mocking gd with something other than a DOM element?). I will come back to you on this tomorrow.

[etpinard]

Good call. Plots.supplyDefaults should work with plain objects.

Could we make this check more robust? I'd vote for using Lib.isPlotDiv.

[etpinard]

we should also check to svg attributes too to make sure that it updated properly.

[etpinard]

@n-riesco looks like you're on the right path.

Replaced { autosize: 'initial' } with the flag gd._fullLayout._initialAutoSizeIsDone

Yep. Great idea. 👍

{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't { autosize: false } lead to layout.width: 700 and layout.height: 400 as per their defaults?

{ autosize: true } only autosizes the values of width and height undefined in gd.layout

Great.

Unfortunately, the plotly.js auto-size routine has very poor test coverage; I'm a little concerned with merging this PR. @n-riesco could make sure that all code paths in plotAutoSize are tested under Plotly.plot and Plotly.relayout?

[n-riesco]

On 30/05/16 17:32, Étienne Tétreault-Pinard wrote:

@n-riescohttps://github.com/n-riesco looks like you're on the right path.
{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't |{ autosize: false }| lead to |layout.width: 700| and |layout.height: 400| as per their defaults?

The current behaviour is that if layout.width or layout.height are undefined, then layout.autosize is set to 'initial'.
When layout.autosize is set to 'initial' (and assuming config.fillFrame is false), plotAutosize gets the layout width and height using window.getComputedStyle(gd). Only if this fails, then the default width and height values are used.

Unfortunately, the plotly.js auto-size has very poor test coverage; I'm a little concerned with the PR. @n-riescohttps://github.com/n-riesco could make sure that all code paths in |plotAutoSize| https://github.com/plotly/plotly.js/pull/577/files#diff-ad4f76ccd6044ed16514297078e13b84R783 are tested under |Plotly.plot| and |Plotly.relayout|.

OK. I'll add more tests.

[alexcjohnson]

@n-riesco this is great, that's definitely where the autosize code belongs.

My only question (which goes along with @etpinard 's concern about test coverage - there are tons of cases to consider) is whether there are cases we'd like autosize to coerce to true - ie if width or height is missing? For example if someone is using element size to determine plot size, but has not explicitly set autosize: true - then something outside the plot (window resize or some event on their page) causes the element size to change, I would expect a simple redraw or relayout to resize the plot too.

This then begs the question (that we probably don't need to delve into now, might be a rabbit hole, but something to keep in mind for later) of whether we actually gain anything with the initial / redraw distinction. Either I'm missing something or it used to work differently, but I don't see that plotAutoSize does anything time-consuming, so what's to stop us from always running it if there's one or more missing dimensions or if autosize is explicitly true? There will be places (relayout?) where we need to track whether anything actually changed to decide how much to do next, but we already do that anyway.

[n-riesco]

Below are the tests I'm planning to add:

• autosize:false, fillFrame:true
• autosize:false, fillFrame:false and frameMargins
• autosize:false, fillFrame:false and no frameMargins
• autosize:true, fillFrame:true
• autosize:true, fillFrame:false and frameMargins
• autosize:true, fillFrame:false and no frameMargins

For each test, I'll check fullLayout width and height after plot and after relayout.

These tests should cover the main execution paths in plotAutoSize.

---

Additional tests (from comments):

• check SVG properties in test 'should respect layout.width and layout.height'
• test supplyDefaults(gd) can be called with mocked gd.

[etpinard]

@n-riesco your plans sounds good!

[n-riesco]

While writing the tests for this PR, I noticed that config accepts the attribute autosizable. In master, this attribute is only honoured by plotPolar. Its meaning in plotPolar is:

• if config.autosizable: false and layout.autosize: false, then no initial autosize is carried out (if needed, the default values of width and height are used);
• if config.autosizable: true, then an initial autosize is carried out (regardless of layout.autosize).

I've updated this PR so that autosizable is always honoured.

[n-riesco]

The PR is ready for review again.

[etpinard]

I think we should avoid using try-catch as much as possible - because they are very slow.

Here too, I'd vote for using Lib.isPlotDiv. But, I'm open to other (possible more strict) suggestions.

[n-riesco]

How about?

vargdBB=fullLayout._container&&fullLayout._container.node ?
fullLayout._container.node().getBoundingClientRect() : {width: fullLayout.width,height: fullLayout.height};

[n-riesco]

@etpinard About autosizable, I think it should be kept in Plotly v1, and removed in Plotly v2. The reason why I think it should be removed is that I don't think autosizable should be a global setting (different plots should be able to define different values of autosizable).

For Plotly v2, I would suggest to combine autosize and autosizable into a single setting. How about something like this?

{autosize: {valType: 'enumerated',role: 'info',values: ['never','initial','always'],description: ['Determines how a layout width or height','that has been left undefined by the user','is set.','If *never*, the default values of width and height will be used.','If *initial*, an undefined layout width or height','will be initialized on the first call to plot.''If *always*, an undefined layout width or height','will be set on the first call to plot and subsequent calls to relayout.'].join(' ')}}

[n-riesco]

PR ready for review again.

[etpinard]

Good. 👍

[etpinard]

Thanks @n-riesco . you're almost there.

As mentioned previously, this PR was set uncover a lot of un-tested code. Commits 172d81d and 862578e were no exceptions.

Would you mind a few test cases (one per commit is fine) for the two commits above? To lock their behavior until v2.0.0.

[n-riesco]

I've added tests for the commits you suggested and this uncovered an issue with 862578e and another with Lib.isPlotDiv. Both are now fixed and tested.

The PR is ready for review again.

[etpinard]

Great. I tested your branch and I couldn't find any edge cases that you might have missed. 🎉

This for sure wins the PR of the week 🏆

I'll make two minor comments on the line diff (nothing major) and then it'll be time to 💃 .

[etpinard]

we should change the valType to 'boolean' and remove the values field.

[etpinard]

@n-riesco , @chriddyp and I are testing the mapbox branch (which is rebased on top of the latest master) in the plot.ly workspace at the moment and we some issues.

Looks like this PR here is backward incompatible and the line ⏫ is a symptom.

More clearly,

Plotly.plot(gd,data);

should go through the plotAutoSize routine on the initial Plotly.plot call.

I believe changing the autosize attribute dflt to true would solve this. What are your thoughts on that?

[n-riesco]

@etpinard An alternative that would be fully backwards-compatible is that Plot.resize(gd) deletes gd.layout.width and gd.layout.height and calls Plotly.relayout(gd, { autosize: true });. I'll prepare a PR so that you can check that it'd fix the issue in the mapbox branch.

[n-riesco]

See #629

[etpinard]

As per-slack conversation with @n-riesco , I'm reverting this PR and will spend more time testing in plot.ly's workspace before the next minor release - to make sure we handle all edge cases in a backward-compatible way.

[n-riesco]

• Moved initial call to plotAutoSize into Plots.supplyDefaults(gd).
• Replaced { autosize: 'initial' } with the flag
  gd._fullLayout._initialAutoSizeIsDone.
• { autosize: false } the values of width and height undefined in
  gd.layout will be autosized only once.
• { autosize: true } only autosizes the values of width and height
  undefined in gd.layout.

Fixes#537

[etpinard]

why do we need this?

[etpinard]

i.e. that if(typeof gd.emit === 'function')

[n-riesco]

Otherwise I get errors in the console (perhaps some test are mocking gd with something other than a DOM element?). I will come back to you on this tomorrow.

[etpinard]

Good call. Plots.supplyDefaults should work with plain objects.

Could we make this check more robust? I'd vote for using Lib.isPlotDiv.

[etpinard]

we should also check to svg attributes too to make sure that it updated properly.

[etpinard]

@n-riesco looks like you're on the right path.

Replaced { autosize: 'initial' } with the flag gd._fullLayout._initialAutoSizeIsDone

Yep. Great idea. 👍

{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't { autosize: false } lead to layout.width: 700 and layout.height: 400 as per their defaults?

{ autosize: true } only autosizes the values of width and height undefined in gd.layout

Great.

Unfortunately, the plotly.js auto-size routine has very poor test coverage; I'm a little concerned with merging this PR. @n-riesco could make sure that all code paths in plotAutoSize are tested under Plotly.plot and Plotly.relayout?

[n-riesco]

On 30/05/16 17:32, Étienne Tétreault-Pinard wrote:

@n-riescohttps://github.com/n-riesco looks like you're on the right path.
{ autosize: false } the values of width and height undefined in gd.layout will be autosized only once.

Hmm. Is this the current behavior? Shouldn't |{ autosize: false }| lead to |layout.width: 700| and |layout.height: 400| as per their defaults?

The current behaviour is that if layout.width or layout.height are undefined, then layout.autosize is set to 'initial'.
When layout.autosize is set to 'initial' (and assuming config.fillFrame is false), plotAutosize gets the layout width and height using window.getComputedStyle(gd). Only if this fails, then the default width and height values are used.

Unfortunately, the plotly.js auto-size has very poor test coverage; I'm a little concerned with the PR. @n-riescohttps://github.com/n-riesco could make sure that all code paths in |plotAutoSize| https://github.com/plotly/plotly.js/pull/577/files#diff-ad4f76ccd6044ed16514297078e13b84R783 are tested under |Plotly.plot| and |Plotly.relayout|.

OK. I'll add more tests.

[alexcjohnson]

@n-riesco this is great, that's definitely where the autosize code belongs.

My only question (which goes along with @etpinard 's concern about test coverage - there are tons of cases to consider) is whether there are cases we'd like autosize to coerce to true - ie if width or height is missing? For example if someone is using element size to determine plot size, but has not explicitly set autosize: true - then something outside the plot (window resize or some event on their page) causes the element size to change, I would expect a simple redraw or relayout to resize the plot too.

This then begs the question (that we probably don't need to delve into now, might be a rabbit hole, but something to keep in mind for later) of whether we actually gain anything with the initial / redraw distinction. Either I'm missing something or it used to work differently, but I don't see that plotAutoSize does anything time-consuming, so what's to stop us from always running it if there's one or more missing dimensions or if autosize is explicitly true? There will be places (relayout?) where we need to track whether anything actually changed to decide how much to do next, but we already do that anyway.

[n-riesco]

Below are the tests I'm planning to add:

• autosize:false, fillFrame:true
• autosize:false, fillFrame:false and frameMargins
• autosize:false, fillFrame:false and no frameMargins
• autosize:true, fillFrame:true
• autosize:true, fillFrame:false and frameMargins
• autosize:true, fillFrame:false and no frameMargins

For each test, I'll check fullLayout width and height after plot and after relayout.

These tests should cover the main execution paths in plotAutoSize.

---

Additional tests (from comments):

• check SVG properties in test 'should respect layout.width and layout.height'
• test supplyDefaults(gd) can be called with mocked gd.

[etpinard]

@n-riesco your plans sounds good!

[n-riesco]

While writing the tests for this PR, I noticed that config accepts the attribute autosizable. In master, this attribute is only honoured by plotPolar. Its meaning in plotPolar is:

• if config.autosizable: false and layout.autosize: false, then no initial autosize is carried out (if needed, the default values of width and height are used);
• if config.autosizable: true, then an initial autosize is carried out (regardless of layout.autosize).

I've updated this PR so that autosizable is always honoured.

[n-riesco]

The PR is ready for review again.

[etpinard]

I think we should avoid using try-catch as much as possible - because they are very slow.

Here too, I'd vote for using Lib.isPlotDiv. But, I'm open to other (possible more strict) suggestions.

[n-riesco]

How about?

vargdBB=fullLayout._container&&fullLayout._container.node ?
fullLayout._container.node().getBoundingClientRect() : {width: fullLayout.width,height: fullLayout.height};

[n-riesco]

@etpinard About autosizable, I think it should be kept in Plotly v1, and removed in Plotly v2. The reason why I think it should be removed is that I don't think autosizable should be a global setting (different plots should be able to define different values of autosizable).

For Plotly v2, I would suggest to combine autosize and autosizable into a single setting. How about something like this?

{autosize: {valType: 'enumerated',role: 'info',values: ['never','initial','always'],description: ['Determines how a layout width or height','that has been left undefined by the user','is set.','If *never*, the default values of width and height will be used.','If *initial*, an undefined layout width or height','will be initialized on the first call to plot.''If *always*, an undefined layout width or height','will be set on the first call to plot and subsequent calls to relayout.'].join(' ')}}

[n-riesco]

PR ready for review again.

[etpinard]

Good. 👍

[etpinard]

Thanks @n-riesco . you're almost there.

As mentioned previously, this PR was set uncover a lot of un-tested code. Commits 172d81d and 862578e were no exceptions.

Would you mind a few test cases (one per commit is fine) for the two commits above? To lock their behavior until v2.0.0.

[n-riesco]

I've added tests for the commits you suggested and this uncovered an issue with 862578e and another with Lib.isPlotDiv. Both are now fixed and tested.

The PR is ready for review again.

[etpinard]

Great. I tested your branch and I couldn't find any edge cases that you might have missed. 🎉

This for sure wins the PR of the week 🏆

I'll make two minor comments on the line diff (nothing major) and then it'll be time to 💃 .

[etpinard]

we should change the valType to 'boolean' and remove the values field.

[etpinard]

@n-riesco , @chriddyp and I are testing the mapbox branch (which is rebased on top of the latest master) in the plot.ly workspace at the moment and we some issues.

Looks like this PR here is backward incompatible and the line ⏫ is a symptom.

More clearly,

Plotly.plot(gd,data);

should go through the plotAutoSize routine on the initial Plotly.plot call.

I believe changing the autosize attribute dflt to true would solve this. What are your thoughts on that?

[n-riesco]

@etpinard An alternative that would be fully backwards-compatible is that Plot.resize(gd) deletes gd.layout.width and gd.layout.height and calls Plotly.relayout(gd, { autosize: true });. I'll prepare a PR so that you can check that it'd fix the issue in the mapbox branch.

[n-riesco]

See #629

[etpinard]

As per-slack conversation with @n-riesco , I'm reverting this PR and will spend more time testing in plot.ly's workspace before the next minor release - to make sure we handle all edge cases in a backward-compatible way.