Apparently our flexbox devtools API (from bug 1409083) returns a large float (17895697.05) for the mainMaxSize, if max-width is at its default value of "none". This is NS_UNCONSTRAINEDSIZE (i.e. nscoord_MAX) naively converted to pixels as (2^30 - 1) / 60. We shouldn't do this -- we should detect NS_UNCONSTRAINEDSIZE in this max-size field and report it to the devtools API via some more declarative way. I think dom/flex/FlexItem.cpp is where the nscoord to pixel conversion happens, so that's probably where we should add this special case. (Thanks to Patrick for the report here.)

As the originator of the API, I'm happy to take this if that's helpful.

I'll tag you to review, if that's all right. I'm tentatively planning on just making the FlexItem::MainMaxSize() API return the double representation of +infinity when we have mMainMaxSize == NS_UNCONSTRAINEDSIZE.

...number of pixels.)

commit message was initially a bit borked, but I think I fixed it up. I verified that the tests pass with the code-changes, and fail without the code-changes. The failure message without the code-change looks like: > FAIL Item index 5 has expected (default) mainMaxSize. - got 17895697.05, expected Infinity

Comment on attachment 8995283 [details] Bug 1477856: In flexbox devtools API, report max-width:none as +infinity. r?bradwerth Brad Werth [:bradwerth] has approved the revision. https://phabricator.services.mozilla.com/D2432

Pushed by dholbert@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/33ff92501b9b In flexbox devtools API, report max-width:none as +infinity. r=bradwerth