New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression: width() & height() return 0 for all inline elements #3571

Closed
Krinkle opened this Issue Mar 16, 2017 · 17 comments

Comments

Projects
None yet
7 participants
@Krinkle
Member

Krinkle commented Mar 16, 2017

Description

Select any element on the page that doesn't have an explicit width set via a stylesheet or inline attribute and call .width().

In jQuery 1.x, 3.0.x and 3.1.1 this returns the computed width.

As of jQuery 3.2.0 it returns 0. This is breaking various downstream test suites for Wikimedia and is blocking our upgrade for now.

Link to test case

http://codepen.io/Krinkle/pen/RpjgpR

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Mar 16, 2017

Member

Ugh, it's hard to believe we didn't have a single unit test for that...

I've created a milestone for 3.2.1, this seems serious enough that we'd want a quick patch release before 3.3.0.

Member

mgol commented Mar 16, 2017

Ugh, it's hard to believe we didn't have a single unit test for that...

I've created a milestone for 3.2.1, this seems serious enough that we'd want a quick patch release before 3.3.0.

@mgol mgol added this to the 3.2.1 milestone Mar 16, 2017

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Mar 16, 2017

Member

Caused by #3561.

Member

mgol commented Mar 16, 2017

Caused by #3561.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Mar 16, 2017

Member

Not having style specified via stylesheet or inline is not enough to trigger the issue; the element has to have a computed display: inline value.

The underlying issue is that getComputedStyle on inline elements returns auto.

Member

mgol commented Mar 16, 2017

Not having style specified via stylesheet or inline is not enough to trigger the issue; the element has to have a computed display: inline value.

The underlying issue is that getComputedStyle on inline elements returns auto.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Mar 17, 2017

Member

From the spec getComputedStyle(elem) returns an object with resolved values for various CSS properties for elem. The definition of the resolved value is at:
https://www.w3.org/TR/cssom-1/#resolved-value
For width resolved value is defined in the following way:

If the property applies to the element or pseudo-element and the resolved value of the display property is not none, the resolved value is the used value. Otherwise the resolved value is the computed value.

The width property doesn't apply to inline elements so the computed value is returned instead of the used one (which it doesn't have). And the computed value will always be auto (again, as the property doesn't apply to inline elements).

Whether width is set inline or in the stylesheet on a particular element doesn't matter. The issue is that .width() is broken in 3.2.0 for all inline elements.

Member

mgol commented Mar 17, 2017

From the spec getComputedStyle(elem) returns an object with resolved values for various CSS properties for elem. The definition of the resolved value is at:
https://www.w3.org/TR/cssom-1/#resolved-value
For width resolved value is defined in the following way:

If the property applies to the element or pseudo-element and the resolved value of the display property is not none, the resolved value is the used value. Otherwise the resolved value is the computed value.

The width property doesn't apply to inline elements so the computed value is returned instead of the used one (which it doesn't have). And the computed value will always be auto (again, as the property doesn't apply to inline elements).

Whether width is set inline or in the stylesheet on a particular element doesn't matter. The issue is that .width() is broken in 3.2.0 for all inline elements.

@mgol mgol changed the title from Regression: width() only works when explicitly set to Regression: width() & height() return 0 for all inline elements Mar 17, 2017

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Mar 17, 2017

Member

I'm not sure what we can do to fix this issue and still keep #3193 (i.e. not take transforms into account while computing width/height) & #1724 (support for subpixel values for width/height) fixed. This issue proves getComputedStyle is not enough but offsetWidth doesn't support fractional values while getBoundingClientRect() takes transforms into account.

Choose your poison. :/

Member

mgol commented Mar 17, 2017

I'm not sure what we can do to fix this issue and still keep #3193 (i.e. not take transforms into account while computing width/height) & #1724 (support for subpixel values for width/height) fixed. This issue proves getComputedStyle is not enough but offsetWidth doesn't support fractional values while getBoundingClientRect() takes transforms into account.

Choose your poison. :/

@Krinkle

This comment has been minimized.

Show comment
Hide comment
@Krinkle

Krinkle Mar 17, 2017

Member

@mgol Yeah, the problem is that the semantic purpose behind .width() is split between two very different concepts. On the one side the use case "computed style", with the rough expectation that setting the same value in CSS would essentially be a no-op (ignoring border-box for now). This doesn't apply to inline elements since setting a width does nothing.

<span>foo</span>
<span style="width: 900px;">foo</span>

These will have the same effective width, unless inline-block or block is applied to the span. So it is true that inline elements don't have a width other than 'auto'.

On the other side, there is the use case of "visual size", which semantically maps to getBoundingClientRect() and is often used to decide where to position an element, or to decide whether text will fit in an element. (The first test failure I found when attempting to upgrade to jQuery 3.2.0 was a test failure from an old plugin called jquery.autoEllipsis)

The problem is that until transforms came along, there wasn't really any way the visual size could be different from the size behind the scenes. The missing concept here is "internally drawn size".

As for transforms, I'm not convinced that it's obvious that that they shouldn't be taken into account. I can imagine plenty of use cases where users may've used width() and expect to get the effectively drawn size on the screen. Inclusion of transforms may've very well been considered an improvement or bug fix. Anyhow, considering they weren't included before jQuery 3.0, I can see why we'd want to keep it that way. But, perhaps it's an option to change that behaviour in jQuery 4.0.

Member

Krinkle commented Mar 17, 2017

@mgol Yeah, the problem is that the semantic purpose behind .width() is split between two very different concepts. On the one side the use case "computed style", with the rough expectation that setting the same value in CSS would essentially be a no-op (ignoring border-box for now). This doesn't apply to inline elements since setting a width does nothing.

<span>foo</span>
<span style="width: 900px;">foo</span>

These will have the same effective width, unless inline-block or block is applied to the span. So it is true that inline elements don't have a width other than 'auto'.

On the other side, there is the use case of "visual size", which semantically maps to getBoundingClientRect() and is often used to decide where to position an element, or to decide whether text will fit in an element. (The first test failure I found when attempting to upgrade to jQuery 3.2.0 was a test failure from an old plugin called jquery.autoEllipsis)

The problem is that until transforms came along, there wasn't really any way the visual size could be different from the size behind the scenes. The missing concept here is "internally drawn size".

As for transforms, I'm not convinced that it's obvious that that they shouldn't be taken into account. I can imagine plenty of use cases where users may've used width() and expect to get the effectively drawn size on the screen. Inclusion of transforms may've very well been considered an improvement or bug fix. Anyhow, considering they weren't included before jQuery 3.0, I can see why we'd want to keep it that way. But, perhaps it's an option to change that behaviour in jQuery 4.0.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Mar 17, 2017

Member

@Krinkle you're right .width() has too many responsibilities; this discussion already partially happened in #3193. The problem is any real solution for that would require decoupling those responsibilities which creates a breaking change.

As for what we can do in 3.2.1, anything we do to fix this issue will break something a previous version promised to fix; at this point I think we should just revert Timmy's PR as that will break the thing that we fixed most recently so few people will be relying on that at this point.

The real solution will have to wait for 4.0.

Member

mgol commented Mar 17, 2017

@Krinkle you're right .width() has too many responsibilities; this discussion already partially happened in #3193. The problem is any real solution for that would require decoupling those responsibilities which creates a breaking change.

As for what we can do in 3.2.1, anything we do to fix this issue will break something a previous version promised to fix; at this point I think we should just revert Timmy's PR as that will break the thing that we fixed most recently so few people will be relying on that at this point.

The real solution will have to wait for 4.0.

@craigkovatch

This comment has been minimized.

Show comment
Hide comment
@craigkovatch

craigkovatch Mar 17, 2017

As for transforms, I'm not convinced that it's obvious that that they shouldn't be taken into account.

I agree, but I wonder if a caller-specified parameter (i.e. shouldIncludeTransforms or some such) would be the easier and more flexible path?

craigkovatch commented Mar 17, 2017

As for transforms, I'm not convinced that it's obvious that that they shouldn't be taken into account.

I agree, but I wonder if a caller-specified parameter (i.e. shouldIncludeTransforms or some such) would be the easier and more flexible path?

@HolgerJeromin

This comment has been minimized.

Show comment
Hide comment
@HolgerJeromin

HolgerJeromin Mar 17, 2017

I agree, but I wonder if a caller-specified parameter

The whole api is designed as read: .width() and write: .width(newValue)
So adding a parameter is not easy possible.
I think we really need a new api for proper support the whole mess: .width(), .css('width')

HolgerJeromin commented Mar 17, 2017

I agree, but I wonder if a caller-specified parameter

The whole api is designed as read: .width() and write: .width(newValue)
So adding a parameter is not easy possible.
I think we really need a new api for proper support the whole mess: .width(), .css('width')

@timmywil

This comment has been minimized.

Show comment
Hide comment
@timmywil

timmywil Mar 17, 2017

Member

@craigkovatch @HolgerJeromin Right, but even if we added another method (or signature or whatever) to support adding transforms, there's still this issue of how to support getting width with no transforms correctly.

I wonder if falling back to offsetWidth is the best option. I still lean towards ignoring transforms and erring on the side of whole numbers rather fractional values, but only when the value we get from curCSS is auto.

Member

timmywil commented Mar 17, 2017

@craigkovatch @HolgerJeromin Right, but even if we added another method (or signature or whatever) to support adding transforms, there's still this issue of how to support getting width with no transforms correctly.

I wonder if falling back to offsetWidth is the best option. I still lean towards ignoring transforms and erring on the side of whole numbers rather fractional values, but only when the value we get from curCSS is auto.

@craigkovatch

This comment has been minimized.

Show comment
Hide comment
@craigkovatch

craigkovatch Mar 17, 2017

@timmywil I agree. Better to be missing a fraction of a pixel than be unexpectedly transformed by some scaling factor.

Perhaps it would be good to reach out to W3C/Webkit/Mozilla and ask for a proper API. jQuery isn't the only library that will want to have a correct answer to this question.

craigkovatch commented Mar 17, 2017

@timmywil I agree. Better to be missing a fraction of a pixel than be unexpectedly transformed by some scaling factor.

Perhaps it would be good to reach out to W3C/Webkit/Mozilla and ask for a proper API. jQuery isn't the only library that will want to have a correct answer to this question.

timmywil added a commit to timmywil/jquery that referenced this issue Mar 18, 2017

Dimensions: fall back to offsetWidth/Height for inline elems
- Also added some more general dims tests for inline
  elements for posterity

Fixes gh-3571

timmywil added a commit to timmywil/jquery that referenced this issue Mar 18, 2017

Dimensions: fall back to offsetWidth/Height for inline elems
- Also added some more general dims tests for inline
  elements for posterity

Fixes gh-3571

timmywil added a commit to timmywil/jquery that referenced this issue Mar 18, 2017

Dimensions: fall back to offsetWidth/Height for inline elems
- Also added some more general dims tests for inline
  elements for posterity

Fixes gh-3571

@OlegKi OlegKi referenced this issue Mar 18, 2017

Closed

actions column #301

@mohithg

This comment has been minimized.

Show comment
Hide comment
@mohithg

mohithg Mar 19, 2017

My app relies on width() and height() on inline-elements and updating to 3.2 broke my app too. When is patch going to release?

mohithg commented Mar 19, 2017

My app relies on width() and height() on inline-elements and updating to 3.2 broke my app too. When is patch going to release?

timmywil added a commit to timmywil/jquery that referenced this issue Mar 20, 2017

@timmywil timmywil closed this in 473d2ea Mar 20, 2017

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol
Member

mgol commented Mar 20, 2017

@mohithg

This comment has been minimized.

Show comment
Hide comment
@mohithg

mohithg commented Mar 21, 2017

@mgol Thanks.

stevenbenner added a commit to stevenbenner/jquery-powertip that referenced this issue Mar 27, 2017

Updated jQuery references to version 3.2.1
Important note: jQuery version 3.2.0 had a bug where the value
returned by `.width()` and `.height()` was always zero for inline
elements. This leads to unusual tooltip positioning.

For this reason, PowerTip cannot support jQuery 3.2.0.

Ref: jquery/jquery#3571
Ref: 23cc0d0
@Krinkle

This comment has been minimized.

Show comment
Hide comment
@Krinkle

Krinkle Apr 1, 2017

Member

The fix didn't work for Android 4. Could re-open, but filed #3602 instead.

Member

Krinkle commented Apr 1, 2017

The fix didn't work for Android 4. Could re-open, but filed #3602 instead.

@Camzilla

This comment has been minimized.

Show comment
Hide comment
@Camzilla

Camzilla Dec 15, 2017

@mgol surprisingly ran into this problem today when replacing a table with flex. Items in my rows have "flex: 0 0 value%" and are showing up as '0' width for .height() .innerHeight() and also .outerHeight(). I got jQuery 3.2.1 in my project, is flex accounted for?

Camzilla commented Dec 15, 2017

@mgol surprisingly ran into this problem today when replacing a table with flex. Items in my rows have "flex: 0 0 value%" and are showing up as '0' width for .height() .innerHeight() and also .outerHeight(). I got jQuery 3.2.1 in my project, is flex accounted for?

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Dec 15, 2017

Member

@Camzilla This seems unrelated to this issue. Could you open a new one with a test case?

Member

mgol commented Dec 15, 2017

@Camzilla This seems unrelated to this issue. Could you open a new one with a test case?

restonexyz added a commit to restonexyz/jquery that referenced this issue Feb 3, 2018

up (#1)
* Dimensions: ignore transforms when retrieving width/height

Close gh-3561
Fixes gh-3193

* CSS: remove dead code in getWidthOrHeight

- getCSS already falls back to inline styles

Ref gh-3561

* Release: update release dependencies

* Release: update AUTHORS.txt

* Release: update version to 3.2.0-pre

* Release: md5sum -> md5 -r for MAC

* Build: Updating the master version to 3.2.1-pre.

* Release: edit dist README version on release

Fixes gh-3574

* Build: update PR template

- Comment out things we don't need to see in the PR description
- Change CLA link

* Tests: move readywait to an iframe test

Close gh-3576
Fixes gh-3573

* Dimensions: fall back to offsetWidth/Height for inline elems

Close gh-3577
Fixes gh-3571

* Revert "Event: Trigger checkbox and radio click events identically"

This reverts commit b442aba.

* Revert "Event: Add radio click triggering tests"

This reverts commit 5f35b5b.

* Tests: add test for passing trigger data to radio click handler

Close gh-3581
Fixes gh-3579

* Build: Updating the master version to 3.2.2-pre.

* CSS: retrieve inline style before computed

- Fixes an issue with getting computed style on detached elements

* Revert "Build: Updating the master version to 3.2.2-pre."

This reverts commit 066bd86.

* Build: Updating the master version to 3.2.2-pre.

* Tests: Fix incorrect assert name for ensure_iterability_es6

Closes gh-3584
Ref bb026fc.

* Docs: Update links to HTML spec for stripAndCollapse (#3594)

* Offset: Use correct offset parents; include all border/scroll values

Thanks @anseki

Fixes gh-3080
Fixes gh-3107
Closes gh-3096
Closes gh-3487

* Core: Update isFunction to handle unusual-@@toStringTag input

Ref gh-3597
Fixes gh-3600
Fixes gh-3596
Closes gh-3617

* Tests: Improve offset test setup and labels

Hopefully this fixes iOS testing: http://swarm.jquery.org/job/5226

Ref 1d2df77
Closes gh-3641

* Tests: Be even more async for iOS

Ref 1d2df77
Closes gh-3643

* Tests: Attach test iframes to the body for visibility-dependent code

Ref 1d2df77
Closes gh-3645

* Tests: Allow a mock QUnit.test for perfect testIframe fidelity

Ref 1d2df77
Closes gh-3647

* Tests: Prepend test iframes for even *more* consistency

Ref 1d2df77

* Tests: Reset iframe window scroll after updating html/document position

Ref 1d2df77
Closes gh-3649

* Tests: Add debugging to investigate iOS failures

Ref 1d2df77

* Tests: Keep iframes visible in TestSwarm

Ref 1d2df77

* Tests: Adjust by actual scroll position, rather than expected

Ref 1d2df77

* Tests: Clean up offset debugging

Ref 1d2df77
Ref c0edd8d

* Tests: Correct expected assertion count

Ref e94b5b0

* Tests: Revert some testIframe changes to fix dimensions tests

Ref c0edd8d

* Revert "Tests: Revert some testIframe changes to fix dimensions tests"

This reverts commit c4368a9.

* Tests: Revert some testIframe changes to fix dimensions tests

Ref c0edd8d

* CSS: Drop the float mapping from cssProps

Firefox 35 and newer support style.float directly.

Closes #3569

* Docs:Tests: Update IE/Edge-related support comments & tests

Closes gh-3661

* Build: Test on Node.js 8, stop testing on Node.js 7

* Tests: minor typos

Close gh-3671

* Dimensions: Include scroll gutter in "padding" box

Fixes gh-3589
Closes gh-3656

* Deferred: fix memory leak of promise callbacks

Fixes gh-3606
Closes gh-3657

* Build: update node dependencies; commit package-lock.json

- Also ignore yarn.lock
Close gh-3669

* Build: Update sinon, husky, and qunitjs

* Build: fix uglify options for uglify update

- Uses new typeofs option for compression
- See mishoo/UglifyJS2#2198

Close gh-3710

* Event: `stopPropagation()` on native event-handler

Fixes gh-3693
Close gh-3694

* Core: Deprecate jQuery.isWindow

Fixes gh-3629
Close gh-3702

* Test: ensure position/offset return mutable objects

Fixes gh-3612
Closes gh-3695

* Revert "Offset: Resolve strict mode ClientRect "no setter" exception"

This reverts commit 3befe59.

* Offset: fix error from bad merge in #3695

* Dimensions: Detect and account for content-box dimension mishandling

Fixes gh-3699
Closes gh-3700

* Support: Properly check for IE9 absolute scrollbox mishandling

Ref gh-3589
Fixes gh-3699
Fixes gh-3730
Closes gh-3729

* Tests: Try extra hard to control focus

Ref gh-3732

* Tests: Abort focus tests when the environment doesn't cooperate

Ref gh-3732

* Tests: Reduce the abort timeout for simple focus testing

Ref gh-3732

* Tests: Simulate events when CI hinders use of native ones

Ref gh-3732

* Tests: Account for TestSwarm focus issues

Closes gh-3732

* Ajax: add an ontimeout handler to all requests

Fixes gh-3586
Close gh-3590

* Dimensions: Improve offsetWidth/offsetHeight fallback

Fixes gh-3698
Fixes gh-3602
Closes gh-3738

* Tests: Replace non-ASCII whitespace in source code

* Dimensions: Don't trust non-pixel computed width/height

Fixes gh-3611
Closes gh-3741

* Build: Fix comment typo

Closes gh-3747

* Build: Update my name in .mailmap

I got married! 🎉

* Build: Update my name in ATHORS.txt

I forgot .mailmap isn't everything.

* Tests: Update path calculation

Fixes gh-3756
Closes gh-3757

* CSS: Avoid unit-conversion interference from CSS upper bounds

Fixes gh-2144
Closes gh-3745

* Tests: Update lineHeight adjustments to give Android more slop

* CSS: Detect more WebKit styles erroneously reported as percentages

Ref 692f9d4
Fixes gh-3777
Closes gh-3778

* Build: Update to Babel 7, use for-of plugin instead of preset-es2015

Closes gh-3786

* Build: Drop cross-spawn, use child_process.spawn shell option

* Build: increase timeout in Promises/A+ tests 10 times

The promises-aplus-tests sets up a default 200 ms Mocha timeout. This makes
our tests randomly fail on Jenkins. 2 seconds will be safer.

Closes gh-3791

* Build: Remove package-lock.json, add it to .gitignore

npm 5, even the version included in the latest Node.js 8.5.0 re-generates
`package-lock.json` on each install. And when it does on a system that doesn't
support all the optional dependencies that are supported on the OS where the
lockfile was generated, it removes those optional deps from the lockfile.

The effect is that everyone firing `npm install` on our repo on any OS other
than macOS will immediately get a dirty state of the repo as the `fsevents`
dependency subtree gets removed from `package-lock.json`. That's a really bad
experience.

This commit removes package-lock.json from the repository and adds it to
.gitignore. We'll start committing the file again once the issue is resolved
on npm's part.

Fixes gh-3792

* Tests: Make Node tests work for paths with spaces in them

Without this patch Jenkins tests fail as jQuery job names there contain spaces,
e.g. "jQuery Core".

Closes gh-3821

* Tests: Add Safari 11 support test results

* Build: Test on Node.js 9

Closes gh-3840

* Tests: Add iOS 11 support test results

* Manipulation: Reduce size by eliminating single-use variable

Closes gh-3851

* CSS: Correctly set support properties with non-default zoom

Fixes gh-3808
Closes gh-3872

* Docs: Create CODE_OF_CONDUCT.md

Close gh-3865

* Tests: Add support for running unit tests via grunt with karma

- Update QUnit to 1.23.1
- Remove unused dl#dl from test/index.html
- Remove unused map#imgmap from test/index.html
- Ensure all urls to data use baseURI
- Add the 'grunt karma:main' task
  - customContextFile & customDebugFile
- Add 'npm run jenkins' script

Close gh-3744
Fixes gh-1999

* Build: Only run browser tests in one Node version on Travis

Ref gh-3744
Closes gh-3894

* Core: make camelCase function available only for internal usage

Close gh-3604
Fixes gh-3384

* Core: adjust data tests to ensure proper camelCasing

- Add back camelCase to the public object (deprecate not remove)
Ref #3384

* Core: deprecate jQuery.now

Fixes gh-2959
Close gh-3884

* Core: deprecate jQuery.proxy (not slated for removal)

Fixes gh-2958
Close gh-3885

* Manipulation: use `.children` to select tbody elements

- selectors beginning with a child combinator are not valid natively.
  This fixes the tests when using selector-native.js

* Attributes: allow array param in add/remove/toggleClass

+30 bytes instead of +182

Thanks to @faisaliyk for the first pass on this feature.

Fixes gh-3532
Close gh-3917

* Ajax: add unit test for getScript(Object)

Fixes gh-3736
Close gh-3918

* Tests: only run ontimeout test if ontimeout exists

Fixes gh-3742
Close gh-3919

* Build: Fix UglifyJS output in Android 4.0; update uglify

- Thanks to @mgol for first pass

Fixes gh-3743
Close gh-3920

* Tests: fix function reference for unbinding

Ref gh-2958

* Build: Remove CRLF line endings to fix builds on Windows

Close gh-3929

* Core: deprecate jQuery.isFunction

Fixes gh-3609

* Event: Move event aliases to deprecated

Fixes gh-3214

* Ajax: Don't process non-string data property on no-entity-body requests

Fixes gh-3438
Closes gh-3781

* Core: deprecate jQuery.isNumeric

Fixes gh-2960
Closes gh-3888

* Tests: fix weird failure in Edge 16 CSS

Fixes gh-3866
Close gh-3932

* Tests: fix weird flaky attributes test in Edge 16

Fixes gh-3867
Close gh-3931

* Core: deprecate jQuery.type

Fixes gh-3605
Close gh-3895

* Tests: fix number of expected assertions in basic core

* Tests: temporarily require sudo access for karma:main on travis

- This should fix the broken travis build on Node 8
- See travis-ci/travis-ci#8836

* Tests: correctly set sudo in travis config, not karma config

* Manipulation: Add support for scripts with module type

Fixes gh-3871
Close gh-3869

* Tests: fix tests in AMD mode

* Tests: ensure that module assertions run on supported browsers

- Also fixes tests for karma, where the URL for the module is different

Ref gh-3871

* Filter: Use direct filter in winnow

for both simple and complex selectors

Fixes gh-3272
Closes gh-3910

* Build: Add "-debug" suffix to name of karma debug tasks

Ref gh-3922
Close gh-3936

* Tests: skip test with invalid selector for selector-native tests

* Release: add new authors to AUTHORS.txt

* Release: update version to 3.3.0-pre

* Build: Updating the master version to 3.3.1-pre.

* Build: Updating the master version to 3.3.2-pre.

rajadain added a commit to WikiWatershed/model-my-watershed that referenced this issue Feb 6, 2018

rajadain added a commit to WikiWatershed/model-my-watershed that referenced this issue Feb 6, 2018

rajadain added a commit to WikiWatershed/model-my-watershed that referenced this issue Feb 8, 2018

@lock lock bot locked as resolved and limited conversation to collaborators Jun 17, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.