Closed Bug 1274096 Opened 9 years ago Closed 8 years ago

Supporting "display: -webkit-flex" as an alias for "display: flex" (and associated properties)

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla49
Tracking Flags:
Tracking Status
firefox48 --- fixed
firefox49 --- fixed

People

(Reporter: dholbert, Assigned: dholbert)

References

Details

(Keywords: dev-doc-complete)

Attachments

(2 files)

MozReview Request: Bug 1274096 part 1: Add support for webkit-prefixed aliases of modern flexbox CSS properties. r?mats
58 bytes, text/x-review-board-request
MatsPalmgren_bugz
: review+
Sylvestre
: approval-mozilla-aurora+
Details
MozReview Request: Bug 1274096 part 2: Add support for "-webkit-flex" & "-webkit-inline-flex" as spellings of modern flexbox "display" keywords, if webkit prefix support is enabled. r?mats
58 bytes, text/x-review-board-request
MatsPalmgren_bugz
: review+
Details
Filing this bug for a possible problem (not 100% sure whether or not it's bad enough that we need to address it). SO, I've run across two cases* recently where a site has CSS ordering like: > .foo { > /* Flexbox display values: */ > display:flex; > display: -webkit-box; /* OLD - iOS 6-, Safari 3.1-6 */ > display: -webkit-flex; /* NEW - Chrome */ > > /* Styles which are required for the page to render correctly, and > which only work if this element is a modern flex container: */ > flex-direction: column; > align-items: center; > } Sites with CSS like that ^^ will experience rendering regressions when the layout.css.prefixes.webkit pref is enabled (i.e. when bug 1259345 hits release). In particular: Firefox release only recognizes the first "display" value, Firefox Nightly (with layout.css.prefixes.webkit) recognizes the first and second, and Chrome recognizes all three. So Firefox release and Chrome end up with modern flexbox (display:flex/display:-webkit-flex), but Firefox Nightly ends up with emulated old-school flexbox (-webkit-box). This means Firefox Nightly won't honor e.g. the "flex-direction" property specified further down. This is only an issue because the site has two problems: (1) It's got its display values in the wrong order - best practice is to have the most-modern property listed last. (2) It's using "display:-webkit-box" without actually providing useful values for the "-webkit-box" associated properties. So really, in cases like this, the site should just fix one or both of these issues. (1) in particular should be trivial for them to fix. But depending on how common this is, it might create an unsustainable Tech Evang burden. So: we might just need to add support for "display: -webkit-flex" as an alias for "display:flex", so that we'll recognize all three "display" values just like Chrome does. * The two cases where I ran across this are: (1) https://github.com/webcompat/web-bugs/issues/2528#issuecomment-217563748 (2) http://stackoverflow.com/questions/37306138/flexbox-not-working-properly-on-firefox-but-okay-on-chrome-safari (Note that the actual question in that post is about a different issue -- `-moz-box` messing things up -- but the CSS quoted by the questioner there reveals that the site in question will be susceptible to this problem, too.)
Summary: Consider support "display: -webkit-flex" as an alias for "display: flex" (and associated properties) → Consider supporting "display: -webkit-flex" as an alias for "display: flex" (and associated properties)
Blocks: 1259345
Local testing indicates that Edge does support "display:-webkit-flex" as an alias for "display:flex", as well as webkit-prefixed versions of the associated properties listed here: https://drafts.csswg.org/css-flexbox-1/#property-index Here's the testcase I used for that: https://jsfiddle.net/yhsvzwt5/ We've deferred to Edge's research & final decisions on webkit-aliasing-worthiness before; we probably should in this case as well. Astley, does someone on your team have cycles for this? Should be pretty straightforward -- we need to do the following things: SUPPORTING THE NEW PROPERTY ALIASES: (1) Add webkit prefix macro invocations for each of these properties... https://drafts.csswg.org/css-flexbox-1/#property-index ...to this file: http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSPropAliasList.h?rev=c0a618d9fa6f#360 ...and also add blocks to this file so they get tested: http://mxr.mozilla.org/mozilla-central/source/layout/style/test/property_database.js?rev=cf57eb3d5080#7379 SUPPORTING THE NEW VALUES FOR THE "display" PROPERTY: (2) We need to add "-webkit-flex" and "-webkit-inline-flex" as CSS Keywords, here: http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSKeywordList.h?rev=0daf8488dbda#128 (3) We need to add mappings from those keywords to our internal enum for the modern flexbox keywords (NS_STYLE_DISPLAY_FLEX / ...INLINE_FLEX) to kDisplayKTable, adjacent to the webkit-box stuff, here: http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSProps.cpp?rev=0daf8488dbda#1287 (4) We need to update "WebkitPrefixEnabledPrefChangeCallback" in nsLayoutUtils to stomp on these new kDisplayKTable entries when the pref changes (like we already do for -webkit-box/-webkit-inline-box). (5) We need to add a test to ensure that "display:-webkit-flex" and "display: -webkit-inline-flex" have an effect.
Flags: needinfo?(aschen)
(I'm also happy to take this myself, too.)
Actually, I'm just going to take this myself, in the interests of getting it fixed ASAP, so that we can uplift it to 48 ASAP. (I want to do that so that we can enable webkit prefix support on beta48 for a trial period -- see bug 1259345 comment 16 for more details. I anticipate that this bug here might be a source of pain / breakage for users & sites during that trial period, so I want to have this fixed before the beta48 trial.)
Assignee: nobody → dholbert
Flags: needinfo?(aschen)
Summary: Consider supporting "display: -webkit-flex" as an alias for "display: flex" (and associated properties) → Supporting "display: -webkit-flex" as an alias for "display: flex" (and associated properties)
Comment on attachment 8755037 [details] MozReview Request: Bug 1274096 part 1: Add support for webkit-prefixed aliases of modern flexbox CSS properties. r?mats https://reviewboard.mozilla.org/r/54350/#review51044 ::: layout/style/nsCSSPropAliasList.h:371 (Diff revision 1) > +CSS_PROP_ALIAS(-webkit-flex-flow, > + flex_flow, > + WebkitFlexFlow, > + WEBKIT_PREFIX_PREF) > +CSS_PROP_ALIAS(-webkit-order, > + order, So this would affect grid IIUC: selector { display:grid; -webkit-order: 99; } What does Chrome do (with grid enabled) in this case? Same question for the align/justify aliases. (The other ones looks flexbox-specific.)
Attachment #8755037 - Flags: review?(mats)
I assume/expect they're literally just property aliases -- anything else seems like it'd be probably-crazy -- but I'll test to be sure... (Also: I'm writing a mochitest to assert that "display:-webkit-flex"/"-webkit-inline-flex" is accepted and produces a computed value of "flex"/"inline-flex". I'll attach that as "part 3".)
https://webkit.org/blog/6131/updating-our-prefixing-policy/ "We’ll be evaluating existing features on a case-by-case basis. We expect to significantly reduce the number of prefixed properties supported over time but Web compatibility will require us to keep around prefixed versions of some features." Can we perhaps convince them to drop the prefix on -webkit-order and the align/justify properties NOW?
BTW, do we have any evidence that all these properties are needed for web compat? Looking at the example in comment 0, it is using 'align-items' unprefixed...
s/all these/the non-flexbox/ in the last comment. The flexbox-specific ones are probably fine to add anyway.
(In reply to Mats Palmgren (:mats) from comment #8) > https://webkit.org/blog/6131/updating-our-prefixing-policy/ > "We’ll be evaluating existing features on a case-by-case basis. We expect to > significantly reduce the number of prefixed properties supported over time > but Web compatibility will require us to keep around prefixed versions of > some features." > > Can we perhaps convince them to drop the prefix on -webkit-order and the > align/justify properties NOW? -webkit-order usage is pretty high: https://www.chromestatus.com/metrics/css/timeline/popularity/495 -webkit-justify-content is higher: https://www.chromestatus.com/metrics/css/timeline/popularity/493 -webkit-align-content less high, but way higher than the typical removal threshhold: https://www.chromestatus.com/metrics/css/timeline/popularity/478
Addressing comment 6: Chrome does honor these prefixed alignment/order properties in grid, just as I was expecting (i.e. they're just aliases). (I opened grid-justify-content-001.html in Chrome, and adjusted a "justify-content:center" declaration to use "-webkit-justify-content:center" instead. That change did not affect the rendering. But removing the declaration did affect the rendering. So, -webkit-justify-content has the same effect as justify-content for grid. And I did a similar experiment on "order" with "grid-order-placement-auto-001.html".)
(In reply to Mike Taylor [:miketaylr] from comment #11) > -webkit-order usage is pretty high: > https://www.chromestatus.com/metrics/css/timeline/popularity/495 Do you know what the "page loads that use this property" actually means there? I find it hard to believe that ~8% of all page loads have a flexbox with -webkit-order applied. Then again, if Facebook or some other big site use it then it might explain it.
Does Chrome and/or Safari support order/align/justify unprefixed as well?
(In reply to Mats Palmgren (:mats) from comment #9) > BTW, do we have any evidence that all these properties are needed for web > compat? > Looking at the example in comment 0, it is using 'align-items' unprefixed... My CSS in comment 0 was just an example of how we could get into trouble (and regress our rendering) by supporting "display:-webkit-box" without *also* adding "display:-webkit-flex" support. "Part 2" is clearly sufficient to fix that CSS. HOWEVER: if we only take part 2, we're opening ourselves up to failing on sites from before Safari/Chrome unprefixed that have... /* no-flexbox fallback CSS: */ ...set elements to be floats, or table cells, or something... /* flexbox CSS */ display: -webkit-flex; -webkit-flex-direction: -webkit-align-items: center; -webkit-justify-content: center; In that sort of scenario, "Part 2" patch on its own (only supporting "display: -webkit-flex") could make us go the tested reliable currently-working fallback behavior, to some sort of weird untested behavior with an unstyled flexbox. (Or it could make it go from one broken layout to a different broken layout. There will surely be websites in each category.) (In reply to Mats Palmgren (:mats) from comment #13) > Do you know what the "page loads that use this property" actually means > there? It means "page loads that have this property in a stylesheet". In most of those cases, the page probably also provides unprefixed "order" (so we'd be fine not supporting the prefixed version). But there's no way to know how many are in the other category of only using "-webkit-order" (and relying on it, when display:-webkit-flex is supported). (In reply to Mats Palmgren (:mats) from comment #14) > Does Chrome and/or Safari support order/align/justify unprefixed as well? They do currently. They didn't always, though. So, there surely exists content from before they unprefixed which only has prefixed styles. I don't know how much content like that there is, but I don't want to *regress* our rendering on that content (in scenarios like the one I laid out higher up in this comment).
("There's no way to know" was maybe overstating it -- what I meant was "chrome does not have metrics on how often people provide one without the other". We could try to collect those metrics, but to do so would delay shipping webkit prefix support, which would be unfortunate. Also, Microsoft already did a bunch of research / metrics-collection when making their decisions about which prefixed aliases to support in Edge, and they came down on the side of supporting all these properties -- see Comment 1.)
(In reply to Mats Palmgren (:mats) from comment #8) > Can we perhaps convince them to drop the prefix on -webkit-order and the > align/justify properties NOW? I doubt it, honestly.
> My CSS in comment 0 was just an example Oh, ok, I thought it was a snippet from a site. (He, I missed the .foo there) > in Edge, and they came down on the side of supporting all these properties ... supporting all these properties *in flexbox* layout I presume? > I doubt it, honestly. Yeah, I agree it's too late for flexbox.
(In reply to Mats Palmgren (:mats) from comment #10) > s/all these/the non-flexbox/ in the last comment. > The flexbox-specific ones are probably fine to add anyway. One thought on this - so, from the perspective of legacy & current content (which is the content I'm concerned with supporting & not-awkwardly-breaking-as-in-comment 15 here), *all* of these properties (including "order", "align-items", etc) are flexbox-specific. These properties all came into existence as part of the flexbox spec, and they all currently only apply in a flexbox context in currently-shipping browser releases. Some of them (e.g. the ones that were promoted into css-align) *will* end up having an effect on other rendering modes in the future (in Firefox as well as in Chrome/Safari/Edge). But authors won't have a good reason to bother relying on the prefixed versions in those unprefixed future sites. (except maybe via muscle memory & bad habits) (Though if they do use prefixed styles, they'll still end up with sites that work everywhere but Firefox, if we don't take part 1 here.) (And if they do, and the web grows to depend on these prefixed aliases, it's not the end of the world -- aliases are cheap and trivial to maintain, if we have to do so. And that Apple blog post [combined with Blink's prefixing/unsupporting policy] does mean we can rejoice that the set of these prefixed aliases *is bounded* and will hopefully shrink over time. But even if it does not shrink, it's at least bounded.) (In reply to Mats Palmgren (:mats) from comment #18) > > in Edge, and they came down on the side of supporting all these properties > > ... supporting all these properties *in flexbox* layout I presume? Supporting all these properties *as aliases for the unprefixed versions*. They only happen to do anything in flexbox, because that's the only place that Edge has support for the unprefixed versions, AFAIK.
It seems rather unfortunate to ship Grid with support for these prefixed properties when there currently are no web content that depends on them. :-( If we restrict them to Flexbox then there is a greater chance we can remove them some day.
Rego, how hard hard would it be to *not* support the prefixed properties -webkit-order, -webkit-justify-* and -webkit-align-* for grid boxes in WebKit/Blink? (i.e. to restrict the usage to Flexbox only)
Flags: needinfo?(rego)
It'd be hard to restrict them to flexbox while still having them be aliases, IMO. e.g. suppose we have: <div class="align-self: center;-webkit-align-self: space-around;"></div> Are you promosing that getComputedStyle().alignSelf on that element should change based on the "display" value of its parent? That seems quite complex to implement, and needlessly-complex...
I don't think the possibility of Blink/WebKit unprefixing at some point in the future should influence us shipping this or not.(In reply to Mats Palmgren (:mats) from comment #13) > (In reply to Mike Taylor [:miketaylr] from comment #11) > > -webkit-order usage is pretty high: > > https://www.chromestatus.com/metrics/css/timeline/popularity/495 > > Do you know what the "page loads that use this property" actually means > there? > I find it hard to believe that ~8% of all page loads have a flexbox with > -webkit-order applied. Then again, if Facebook or some other big site > use it then it might explain it. Yeah, it's tricky to tease this apart from rules that contain both prefixed and unprefixed. AFAICT, Chrome is measuring any -webkit-order property value that it parses (and treats as an alias as order). https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/css/parser/CSSPropertyParser.cpp&sq=package:chromium&type=cs&l=100&rcl=1463771930 https://code.google.com/p/chromium/codesearch#chromium/src/out/Debug/gen/blink/core/CSSPropertyNames.h&q=CSSPropertyAliasWebKitOrder&sq=package:chromium&type=cs&l=478 (See https://chromium.googlesource.com/chromium/src/+/ef0bbaa58e53dc720970aec40a06f24ca66f7b0d%5E%21/, for a diff when morten unprefixed multicol and made prefixed multicol aliases of unprefixed in Blink) That said, Chrome won't be dropping these prefixes any time soon. So we should add them until that glorious day in the distant future.
Comment on attachment 8755038 [details] MozReview Request: Bug 1274096 part 2: Add support for "-webkit-flex" & "-webkit-inline-flex" as spellings of modern flexbox "display" keywords, if webkit prefix support is enabled. r?mats Review request updated; see interdiff: https://reviewboard.mozilla.org/r/54352/diff/1-2/
Added a mochitest for "display:-webkit-flex" serializing/computing as "display:flex" (and similar for -webkit-inline-flex) to part 2 now, to test the code in that patch.
> AFAICT, Chrome is measuring any -webkit-order property value that it parses I would assume most web developers knows to put the unprefixed declaration last, and there are JS frameworks out there that automates generating such rules. So it wouldn't surprise me if the number of page loads that actually depends on parsing the prefixed version is 3 or 4 *orders of magnitudes* less than the number of pages it is found on. So, I think Googles data is pretty much useless for making a decision on whether we must support these prefixed properties or not. > Chrome won't be dropping these prefixes any time soon Grid support is still disabled by default in all UAs (AFAIK) so this discussion is NOT about dropping something - it's about avoiding *to introduce* support for -webkit- properties for a feature that doesn't need it for web compat: Grid. It's only needed for Flexbox (if you believe the data is showing that it's needed in the first place). IMHO, we should try to avoid introducing -webkit- properties on Grid if it is at all technically feasible. I believe strongly that it is our responsibility as a UA vendor to not make the -webkit- situation worse than it already is. If we introduce it on Grid we have failed miserably on that responsibility. That said, it may indeed be too hard to limit the support to Flexbox only. I'm not a Style System guru so I don't know if it's technically feasible.
(In reply to Mats Palmgren (:mats) from comment #21) > Rego, how hard hard would it be to *not* support the prefixed properties > -webkit-order, -webkit-justify-* and -webkit-align-* for grid boxes in > WebKit/Blink? (i.e. to restrict the usage to Flexbox only) I'm not sure, but taking a quick look they're just aliases: https://chromium.googlesource.com/chromium/src.git/+/fa6d4cde7dda58b7a11486fd6324c0b78c5bf3e6/third_party/WebKit/Source/core/css/CSSProperties.in#565 I agree with Daniel on comment #22, something like that does't seem easy to implement.
Flags: needinfo?(rego)
(In reply to Mats Palmgren (:mats) from comment #27) > So, I think Googles data is pretty much useless for making a decision on > whether we must support these prefixed properties or not. I agree. My justification here isn't the google data. My position is simply that, if we support "display: -webkit-flex" (and we probably have to, per this bug), then it'd be weird for us *not to* support prefixed versions of the associated properties that were introduced *in the same spec*. Supporting one without the other means we'd get behavior that *no other browser has ever had*, when presented with content like comment 15. That smells like possibility for unforseen breakage to me. As you say, we don't have data here, but I expect that there is content that was created using only prefixed versions of those properties (like comment 15), targeting only mobile web or something. That content has a particular fallback on Firefox right now. If we take "display:-webkit-flex" without supporting the other properties, that content will switch to some weird intermediate not-fallback-and-not-author's-intention rendering. I'd like to avoid that. > this discussion is NOT about dropping something - it's about avoiding > *to introduce* support for -webkit- properties for a feature that doesn't > need it for web compat: Grid. It's only needed for Flexbox (if you > believe the data is showing that it's needed in the first place). We *aren't introducing any grid-specific prefixed properties here. (And I agree we avoid doing that, if at all possible. I expect/hope we can hold Google and Apple to their commitments about new features & flags-not-prefixes there, with "grid-template-rows" etc.) However, that doesn't mean we should prevent authors from applying general prefixed property-aliases to a grid. For example: "box-sizing" and "transform" apply to CSS grid (and many other elements), and we support prefixed versions of those properties. I don't see why we should view the alignment properties in this bug as being any different. > That said, it may indeed be too hard to limit the support to Flexbox only. > I'm not a Style System guru so I don't know if it's technically feasible. Yeah, I think it'd be more trouble than it's worth, and it would be inconsistent with how we & other browsers treat other broadly-applicable prefixed aliases.
(In reply to Mats Palmgren (:mats) from comment #27) > I would assume most web developers knows to put the unprefixed declaration > last (I used to think that too. But it takes just one trending site with a developer who didn't know that to make Firefox look busted https://github.com/webcompat/web-bugs/issues/2528#issuecomment-218016537)
> My position is simply that, if we support "display: -webkit-flex" (and we probably > have to, per this bug), then it'd be weird for us *not to* support prefixed versions > of the associated properties I agree they should be supported on Flexbox. > For example: "box-sizing" and "transform" apply to CSS grid Fwiw, I'd rather not support -webkit- prefixed aliases for those either on Grid.
It might be possible to implement it cheaply like this: Maintain a bit for each property that says if a -webkit- alias was used to set the value. Later when we're about to create a grid box, check if any of the bits are set. If so, don't create a grid box, give them an inline box instead! This way it will be impossible to create a grid if you use -webkit- aliases *in the wrong way*. Since there are only a few aliases that we want to forbid for Grid (e.g. order, justify-*/align-*) we would only need to maintain bits for those. This strategy is a bit like the one used for some new features that are only available over https. If you use http, then you simply don't get the goodies. We could use the same here - if you use -webkit- prefixed aliases *wrongly*, then no Grid for you! Granted, other UA vendors needs to agree to implement that strategy too for it to be effective.
Attachment #8755037 - Flags: review?(mats)
Comment on attachment 8755037 [details] MozReview Request: Bug 1274096 part 1: Add support for webkit-prefixed aliases of modern flexbox CSS properties. r?mats https://reviewboard.mozilla.org/r/54350/#review51206 Not happy about it leaking into Grid, but I guess it's hard to address that without other UA vendors agreeing on some strategy to avoid it. The code looks fine. r=mats
Comment on attachment 8755038 [details] MozReview Request: Bug 1274096 part 2: Add support for "-webkit-flex" & "-webkit-inline-flex" as spellings of modern flexbox "display" keywords, if webkit prefix support is enabled. r?mats https://reviewboard.mozilla.org/r/54352/#review51208
Attachment #8755038 - Flags: review?(mats) → review+
Attachment #8755037 - Flags: review+
Comment on attachment 8755037 [details] MozReview Request: Bug 1274096 part 1: Add support for webkit-prefixed aliases of modern flexbox CSS properties. r?mats https://reviewboard.mozilla.org/r/54350/#review51210
(In reply to Mats Palmgren (:mats) from comment #32) > It might be possible to implement it cheaply like this: > Maintain a bit [...] > Granted, other UA vendors needs to agree to implement that strategy > too for it to be effective. I agree this strategy *might* be workable (with some details / edge cases ironed out), but only if all UAs (Chrome in particular) operated this way, as you say. And I don't see a strong incentive for them to change to take on this complexity, so I think we'll have to settle for simple aliases with later data-driven removals on a case-by-case basis. In any case: thanks for the reviews!
Note: I also had to tweak layout/inspector/tests/test_bug877690.html -- which includes its own hardcoded list of accepted "display" values -- to add "-webkit-flex"/"-webkit-inline-flex", or else that test fails. (I always forget we need to update that test when we add new display values.) I'm not bothering reposting patch, to avoid retriggering MozReview. Try run here, though (with that change): https://treeherder.mozilla.org/#/jobs?repo=try&revision=1dab48edf915 ...and here's the link to the change in that test: https://hg.mozilla.org/try/rev/75dd4935915e27a72aadeecae3c1a4eb5a115a58#l2.2
Looks like we've got a devtools test which has a hardcoded "expected number of valid display values", basically -- I filed bug 1275081 on getting that test improved, and in the meantime I'll bump its count when I land the patches here, to avoid causing test failures.
Comment on attachment 8755037 [details] MozReview Request: Bug 1274096 part 1: Add support for webkit-prefixed aliases of modern flexbox CSS properties. r?mats Requesting backport approval for both patches here, to go to Aurora48, as part of an early-beta48 trial. See bug 1259345 comment 16 and/or this mozilla.compatibility post for context: https://groups.google.com/forum/#!topic/mozilla.compatibility/velpLiTN44Y The code here will be disabled partway through the beta48 cycle. (Exact timing is flexible, but I'm thinking after ~2 weeks of beta.) Discussion on that timing can happen on the mozilla.compatibility post linked above, or on bug 1259345. Approval Request Comment [Feature/regressing bug #]: webkit prefix support (for better web compatibility) [User impact if declined]: Possible layout regressions on sites that incorrectly order their prefixed/unprefixed fallback CSS (as described in comment 0), in Firefox builds with webkit prefix support enabled. [Describe test coverage new/current, TreeHerder]: Tests included. [Risks and why]: - From the perspective of Firefox 48 *release*, this is very low-risk, as this is behind a pref which we're intending to only enable for a short period during 48 beta and then disable. So, this code won't be active in Firefox 48 release. - From the perspective of Firefox 48 early-beta and Aurora, this is moderate to low risk. (This can only affect pages where someone has included "display:-webkit-flex" and/or associated properties without unprefixed fallback [or they've mis-ordered their CSS such that the unprefixed fallback gets stomped on by something else, as in comment 0]. And on those pages, this bug is much more likely to change our rendering for the better than for the worse.) [String/UUID change made/needed]: None.
Attachment #8755037 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/bbd1d5a1fc25 https://hg.mozilla.org/mozilla-central/rev/483b17546c54
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox49: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Comment on attachment 8755037 [details] MozReview Request: Bug 1274096 part 1: Add support for webkit-prefixed aliases of modern flexbox CSS properties. r?mats Low risk on the release, will improve our testing with our beta population, taking it
Attachment #8755037 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Just noticed we only uplifted "part 1" here (without "part 2"). Uplift request was for both patches, as noted in comment 40. So, this isn't fully fixed in DevEdition 48 right now (but it will be once we uplift part 2). I'll uplift part 2 now.
(Part 2's changes to browser_rules_completion-new-property_02.js [the devtools test mentioned in comment 38] don't uplift cleanly, because that test file is different between Aurora & Trunk. I suspect the Aurora version of that test doesn't need a tweak, since it doesn't look like it has the same hardcoded number-of-valid-display-values. But I'll build locally & verify that it still passes, before landing the uplift for part 2.)
Looks good! Thanks.
Flags: needinfo?(dholbert)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: