Percentage max-width does not seem to affect contributions to intrinsic min-width

RESOLVED FIXED in Firefox 46

Status

()

Core
Layout: Block and Inline
RESOLVED FIXED
5 years ago
14 days ago

People

(Reporter: Tim Hunt, Assigned: dbaron)

Tracking

(Depends on: 2 bugs, Blocks: 2 bugs)

Trunk
mozilla47
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox44 affected, firefox45 affected, firefox46 verified, firefox47 verified)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(16 attachments)

668 bytes, text/html
Details
1.69 KB, text/html
Details
1.62 KB, text/html
Details
1.82 KB, text/html
Details
10.09 KB, image/png
Details
10.77 KB, image/png
Details
12.82 KB, image/png
Details
2.17 KB, text/html
Details
178.31 KB, image/png
Details
56.97 KB, image/png
Details
58 bytes, text/x-review-board-request
dholbert
: review+
Details | Review
58 bytes, text/x-review-board-request
dholbert
: review+
Details | Review
58 bytes, text/x-review-board-request
dholbert
: review+
Details | Review
58 bytes, text/x-review-board-request
dholbert
: review+
Details | Review
58 bytes, text/x-review-board-request
dholbert
: review+
Details | Review
58 bytes, text/x-review-board-request
dholbert
: review+
Details | Review
(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232

Steps to reproduce:

I am experiencing this problem with a complex form, but there is a nice explanation at http://stackoverflow.com/questions/10672586/how-to-make-select-elements-shrink-to-max-width-percent-style-within-fieldset, see the "Clarification:" bit, and there is a minimal test-case at http://jsfiddle.net/e2H82/.

Applying min-width: X% to a select drop-down works fine, unless the select is nested somewhere inside a fieldset.

That is, with HTML like
<fieldset style="background:blue;">
 <select name=countries style="max-width:90%;">
  <option value=gs>South Georgia and the South Sandwich Islands</option>
 </select>
</fieldset>
 <select name=countries style="max-width:90%;">
  <option value=gs>South Georgia and the South Sandwich Islands</option>
 </select>


Actual results:

Make the browser window very narrow. The second select starts to shrink when the max-width:90%; kicks in. The first select never gets any narrower.


Expected results:

Both selects should size in the same way.

I think the same bug also affects textareas, but I have not made the same effort to cleanly reproduce that.

As an additional verification, if I use firebug to edit the fieldset tag in my original complex form to a div, then the max-width style rules on the select and textareas start working.

I don't think I have created a duplicate here. Searching, it took ma a long time to find anything (so, if I have created a duplicate, at least it will help people searching). The only vaguely close things I found were:

https://bugzilla.mozilla.org/show_bug.cgi?id=261037
https://bugzilla.mozilla.org/show_bug.cgi?id=504622

Those might possibly be duplicated, but determining that requires more knowledge of the Gecko rendering engine than I posess.
The problem is that percentage max-width on the <select> is a percentage of the width of the <fieldset>.

So the real question is what the width of that <fieldset> is.

And the problem you're running into is that a fieldset will never become narrower than the claimed min-intrinsic width of its kids (bug 504622, as you noted).

That said, it's a bit odd that setting max-width to a percentage doesn't affect the min-intrinsic width the same way that setting width to a percentage does...
Depends on: 504622
David, should we try to have percentage max-width effectively set intrinsic min-width to 0 like percentage width does?  At least as long as the min-width is not set...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(dbaron)
Summary: select inside fieldset ignores max-width → Percentage max-width does not seem to affect contributions to intrinsic min-width
Component: Layout: Form Controls → Layout: Block and Inline
Hmm.  Maybe percentage width doesn't affect intrinsic min-width either in some cases?  Certainly this testcase:

  <!DOCTYPE html>
  <body style="width: 0">
    <div style="float: left; background: green">
      <span style="display: inline-block; width: 100%;
                   background: rgba(255, 0, 0, 0.5)">
        SomeLongText
      </span>
    </div>
  </body>

does not show it doing so.  But it does seem to for <select>; if I replace the <span> there with a <select> the float width collapses to 0...  I have no idea what's going on there.
(Assignee)

Comment 4

5 years ago
(In reply to Boris Zbarsky (:bz) from comment #2)
> David, should we try to have percentage max-width effectively set intrinsic
> min-width to 0 like percentage width does?  At least as long as the
> min-width is not set...

Seems reasonable.  Presumably you'd split the middle part of this && in nsLayoutUtils::IntrinsicForContainer into an ||:

  else if (aType == MIN_WIDTH &&
           // The only cases of coord-percent-calc() units that
           // GetAbsoluteCoord didn't handle are percent and calc()s
           // containing percent.
           styleWidth.IsCoordPercentCalcUnit() &&
           aFrame->IsFrameOfType(nsIFrame::eReplaced)) {
    // A percentage width on replaced elements means they can shrink to 0.
    result = 0; // let |min| handle padding/border/margin
  }


I think the min-width overriding that would be taken care of by the code about 15 lines below.
Flags: needinfo?(dbaron)
Blocks: 441046
Hmm.  If I do it that way, then the percentage max-width will only set min-intrinsic to 0 if there is no explicit width set, right?  What behavior do we want in cases like:

  <img style="width: 100px; max-width: 100%">

?  For what it's worth, it looks like WebKit has the max-width win in that case, while for Opera the behavior is different for <select> and <img> at first glance (for <select> the max-width wins, but for <img> the width wins)...
Flags: needinfo?(dbaron)
In either case, fixing this bug really should fix bug 441046 and bug 434230 if I'm not screwing up my testing.
(Assignee)

Comment 7

5 years ago
(In reply to Boris Zbarsky (:bz) from comment #5)
> Hmm.  If I do it that way, then the percentage max-width will only set
> min-intrinsic to 0 if there is no explicit width set, right?

Ah, true.

> What behavior
> do we want in cases like:
> 
>   <img style="width: 100px; max-width: 100%">
> 
> ?

Hmmm.  I'm not entirely sure.

And, actually, I'm now reconsidering my answer in comment 4, since when 'width' is set we've explicitly thrown away the intrinsic width, whereas when 'max-width' is set, we haven't explicitly thrown it away unless there's a value of 'width', in which case we might want to honor that.

I suppose I should think about this more...
Flags: needinfo?(dbaron) → needinfo?(dbaron)
Blocks: 434230
Blocks: 932996
Blocks: 936088
Blocks: 1047886

Updated

3 years ago
Blocks: 1023118

Comment 8

2 years ago
Created attachment 8582012 [details]
workaround.htm

For me (Win7, FF 36) wrapping the select within an element styled like this
{
 display: table;
 table-layout: fixed;
 width: 100%;
}
fixes the issue (compare with the test case at http://jsfiddle.net/e2H82/).

See also bug 504622.

Updated

2 years ago
Blocks: 1170774

Updated

2 years ago

Comment 9

2 years ago
Webcompat issue https://webcompat.com/issues/1231
Webcompat issue https://webcompat.com/issues/1390
Probably related to this bug.
https://webcompat.com/issues/1461
Yet another one. 
https://webcompat.com/issues/1467
and https://webcompat.com/issues/1477 , I presume
and https://webcompat.com/issues/1640 another one
and https://webcompat.com/issues/1343 Our monthly intrinsic width webcompat issue.
Is it related to this part of the code?
https://dxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutUtils.cpp#4275
Duplicate of this bug: 1139931
Adding another one. https://webcompat.com/issues/376
Adding another one. https://webcompat.com/issues/1728
Blocks: 1215103
Right now I simply assume reports about elements that have max-width:n% set and end up wider than expected are instances of this bug. I volunteer to do some retesting of the dupes I've closed when there is a fix to make sure there isn't some other bug with the same symptom ;)
https://webcompat.com/issues/1533 has *something* to do with max-height/max-width, but I'm not quite sure if it's about this bug or something else..
Duplicate of this bug: 1215103
Adding https://webcompat.com/issues/862
Another issue with max-width
https://webcompat.com/issues/1837
And https://webcompat.com/issues/1838
(Assignee)

Updated

2 years ago
Flags: needinfo?(dbaron)
(Assignee)

Updated

2 years ago
Flags: needinfo?(dbaron)
Adding another one. 
https://webcompat.com/issues/1936
(Assignee)

Comment 27

2 years ago
Need to respond to this thread:
https://lists.w3.org/Archives/Public/www-style/2015Nov/0225.html
(Assignee)

Comment 28

2 years ago
Created attachment 8690286 [details]
some tests with <img>
(Assignee)

Comment 29

2 years ago
Created attachment 8690287 [details]
some tests with empty <input type="button">
(Assignee)

Updated

2 years ago
Attachment #8690287 - Attachment description: some tests with <input type="button"> → some tests with empty <input type="button">
(Assignee)

Comment 30

2 years ago
Created attachment 8690291 [details]
some tests with <input type="button">
(Assignee)

Comment 31

2 years ago
So Gecko and IE11 actually match pretty closely right now; the only differences I see are on the width:% (not min-width or max-width %) cases for the non-empty button, and on the intrinsic width of the empty button.

Chromium is substantially different for anything involving % max-width on image.  But Chromium and IE appear to match exactly on all the <input type="button"> cases.

I'm curious whether WebKit is any different from Chromium, and whether Edge is any different from IE.  (Ubuntu's Webkit-GTK matches Chromium on intrinsic widths but not final widths for the images, and has differences on the empty button, maybe related to margin.)  I can't test Edge.



Do all the testcases duped against this involve max-width on *images*, or are there other sorts of elements involved?
Created attachment 8690324 [details]
First testcase rendered in Edge
Created attachment 8690325 [details]
Second testcase rendered in Edge
Created attachment 8690326 [details]
Third testcase rendered in Edge
(Assignee)

Comment 35

2 years ago
So Edge changed (relative to IE11) on the image testcase so that Edge and Chromium now match on all 3 testcases.
Blocks: 1227140

Comment 36

2 years ago
Created attachment 8695836 [details]
img-testcase.html

Almost most of the layout will be affected, I hope to be able to repair as soon as possible.

Comment 37

2 years ago
Created attachment 8695837 [details]
img-testcase-Firefox.png

Comment 38

2 years ago
Created attachment 8695838 [details]
img-testcase-Chrome.png
(Assignee)

Comment 39

2 years ago
I looked into the Chromium behavior a bit more closely, and now I have patches for this, but I still need to write some tests.
Assignee: nobody → dbaron
(Assignee)

Updated

2 years ago
Flags: needinfo?(dbaron)
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 17 Branch → Trunk
(Assignee)

Comment 40

2 years ago
For what it's worth, patches are:
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/b795a8095781/check-percent-max-width
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/b795a8095781/replaced-sizing-bit
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/b795a8095781/intrinsic-replaced-sizing
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/b795a8095781/percentage-max-width-override

Comment 41

2 years ago
(In reply to David Baron [:dbaron] ⌚UTC-5 from comment #39)
> I looked into the Chromium behavior a bit more closely, and now I have
> patches for this, but I still need to write some tests.

Thank you for your work.
(Assignee)

Comment 42

2 years ago
(In reply to David Baron [:dbaron] ⌚UTC-5 from comment #27)
> Need to respond to this thread:
> https://lists.w3.org/Archives/Public/www-style/2015Nov/0225.html

Responded at https://lists.w3.org/Archives/Public/www-style/2015Dec/0117.html
Another one.
https://webcompat.com/issues/2028

img with max-width: 100% inside a table. So probably related to Bug 434230
Our weekly webcompat issue.
https://webcompat.com/issues/1740

Updated

2 years ago
Blocks: 1095359
Another one.
https://webcompat.com/issues/1805
(Assignee)

Updated

2 years ago
Blocks: 332171
Blocks: 1238900
(Assignee)

Comment 46

2 years ago
Sorry for the delay; picked this up again after holidays, standards meetings, and vacation.

Finished up with one more patch needed to avoid a compatibility regression (for text inputs, which have their own special behavior), and now a try run:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=44bb0fcc6332
(Assignee)

Comment 47

2 years ago
https://treeherder.mozilla.org/#/jobs?repo=try&revision=87d54e79fbeb
(Assignee)

Comment 48

2 years ago
Created attachment 8713919 [details]
MozReview Request: Bug 823483 patch 1 - Check for percentage max-width in addition to percentage width when deciding to ignore intrinsic min-width of replaced elements.  r?dholbert

This (modulo changes in later patches) matches the behavior of Chromium
and Edge.  It increases the set of elements to which this quirky
behavior applies.

Review commit: https://reviewboard.mozilla.org/r/32887/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/32887/
Attachment #8713919 - Flags: review?(dholbert)
(Assignee)

Comment 49

2 years ago
Created attachment 8713920 [details]
MozReview Request: Bug 823483 patch 2 - Add frame state bit to indicate frame classes that do replaced-element-like sizing.  r?dholbert

This is needed for patch 3.

Review commit: https://reviewboard.mozilla.org/r/32889/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/32889/
Attachment #8713920 - Flags: review?(dholbert)
(Assignee)

Comment 50

2 years ago
Created attachment 8713921 [details]
MozReview Request: Bug 823483 patch 3 - Limit effect of percentage width and max-width on intrinsic size to elements with replaced element sizing.  r?dholbert

This reduces the set of elements to which this quirky behavior applies.

This matches the behavior of Chromium and Edge.

Review commit: https://reviewboard.mozilla.org/r/32891/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/32891/
Attachment #8713921 - Flags: review?(dholbert)
(Assignee)

Comment 51

2 years ago
Created attachment 8713922 [details]
MozReview Request: Bug 823483 patch 4 - Make a percentage max-width override a fixed width for replaced element intrinsic size computation.  r?dholbert

This just reorders the if-else chain to change which conditions are
tested first.  Prior to patch 1, the order didn't matter, but with patch
1, the order does matter, and the order that we happened to have was the
opposite of the one that matches Chromium and Edge.

Review commit: https://reviewboard.mozilla.org/r/32893/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/32893/
Attachment #8713922 - Flags: review?(dholbert)
(Assignee)

Comment 52

2 years ago
Created attachment 8713923 [details]
MozReview Request: Bug 823483 patch 5 - Make (again) percentage width on text inputs make intrinsic minimum width be 0.  r?dholbert

This restores the quirky behavior for text inputs, which was removed by
patch 2, but only halfway (for width but not max-width), which matches
Chromium and Edge.

Review commit: https://reviewboard.mozilla.org/r/32895/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/32895/
Attachment #8713923 - Flags: review?(dholbert)
(Assignee)

Comment 53

2 years ago
Created attachment 8713924 [details]
MozReview Request: Bug 823483 patch 6 - Tests  r?dholbert

Our behavior on these tests is reasonably close to matching Chromium
thanks to the combination of patches 1, 3, and 4, and 5.

FIXME: Make min-intrinsic-with-percents-across-elements less platform-specific.

Review commit: https://reviewboard.mozilla.org/r/32897/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/32897/
Attachment #8713924 - Flags: review?(dholbert)
(Assignee)

Comment 54

2 years ago
(In reply to David Baron [:dbaron] ⌚️UTC+11 (busy, returning 8 February) from comment #53)
> FIXME: Make min-intrinsic-with-percents-across-elements less
> platform-specific.

Er, I did that (with the visibility:hidden stuff), but forgot to remove the FIXME.

Updated

2 years ago
Blocks: 1085106
Comment on attachment 8713919 [details]
MozReview Request: Bug 823483 patch 1 - Check for percentage max-width in addition to percentage width when deciding to ignore intrinsic min-width of replaced elements.  r?dholbert

https://reviewboard.mozilla.org/r/32887/#review30165
Attachment #8713919 - Flags: review?(dholbert) → review+
Comment on attachment 8713920 [details]
MozReview Request: Bug 823483 patch 2 - Add frame state bit to indicate frame classes that do replaced-element-like sizing.  r?dholbert

https://reviewboard.mozilla.org/r/32889/#review30167
Attachment #8713920 - Flags: review?(dholbert) → review+
Comment on attachment 8713921 [details]
MozReview Request: Bug 823483 patch 3 - Limit effect of percentage width and max-width on intrinsic size to elements with replaced element sizing.  r?dholbert

https://reviewboard.mozilla.org/r/32891/#review30171
Attachment #8713921 - Flags: review?(dholbert) → review+
Attachment #8713922 - Flags: review?(dholbert) → review+
Comment on attachment 8713922 [details]
MozReview Request: Bug 823483 patch 4 - Make a percentage max-width override a fixed width for replaced element intrinsic size computation.  r?dholbert

https://reviewboard.mozilla.org/r/32893/#review30175
Attachment #8713923 - Flags: review?(dholbert) → review+
Comment on attachment 8713923 [details]
MozReview Request: Bug 823483 patch 5 - Make (again) percentage width on text inputs make intrinsic minimum width be 0.  r?dholbert

https://reviewboard.mozilla.org/r/32895/#review30177
Comment on attachment 8713924 [details]
MozReview Request: Bug 823483 patch 6 - Tests  r?dholbert

https://reviewboard.mozilla.org/r/32897/#review30179

(Remember to drop the FIXME from your extended commit message before landing; you've probably already done that locally.)

::: layout/reftests/css-sizing/min-intrinsic-with-percents-across-elements-ref.html:2
(Diff revision 1)
> +<title>Tests for bug 823483</title>

Consider s/Tests/Reference/ in the reference case title, so that it's easier to tell which file is which when viewing the testcase & reference case alongside each other (by simply looking at the titlebar).

(I can't quickly tell which is which from the URL bar, because the "-ref.html" suffix is pushed off the end of the URL bar.)

::: layout/reftests/css-sizing/min-intrinsic-with-percents-across-elements-ref.html:43
(Diff revision 1)
> +  <td>canvas, unstyled</td>

Observation: from diffing the testcase & reference case, it looks like the "unstyled"/"almost-unstyled" cases use identical markup between the testcase & reference case.

So, I'm not sure those chunks are technically testing anything, since the identical markup will clearly render the same between testcase & reference case.

I guess you have them there for completeness, which makes some sense. If you can think of a way to make them more usefully tested, great; otherwise, not a big deal I suppose.

::: layout/reftests/css-sizing/min-intrinsic-with-percents-across-elements.html:122
(Diff revision 1)
> +

Nit: There's a stray blank line before the close-brace of the "for" loop in each file here.

That probably wants to be removed, though it doesn't matter much.
Attachment #8713924 - Flags: review?(dholbert) → review+
(Assignee)

Comment 61

2 years ago
(In reply to Daniel Holbert [:dholbert] from comment #60)
> So, I'm not sure those chunks are technically testing anything, since the
> identical markup will clearly render the same between testcase & reference
> case.
> 
> I guess you have them there for completeness, which makes some sense. If you
> can think of a way to make them more usefully tested, great; otherwise, not
> a big deal I suppose.

Yeah, not sure I can think of anything useful to do with them, and probably not worth spending time on it.
(Assignee)

Comment 62

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/ee0ff2c8be1bf45c2431b4010ff1fe068a286400
Bug 823483 patch 1 - Check for percentage max-width in addition to percentage width when deciding to ignore intrinsic min-width of replaced elements.  r=dholbert

https://hg.mozilla.org/integration/mozilla-inbound/rev/3705a4614be0c45f3850deee4f1266ec92521fc7
Bug 823483 patch 2 - Add frame state bit to indicate frame classes that do replaced-element-like sizing.  r=dholbert

https://hg.mozilla.org/integration/mozilla-inbound/rev/d68daa674f403de8093ea36b03825bbff493fe25
Bug 823483 patch 3 - Limit effect of percentage width and max-width on intrinsic size to elements with replaced element sizing.  r=dholbert

https://hg.mozilla.org/integration/mozilla-inbound/rev/b34ebd7afb7811db1ef5ba36dc5c22153c99d5ce
Bug 823483 patch 4 - Make a percentage max-width override a fixed width for replaced element intrinsic size computation.  r=dholbert

https://hg.mozilla.org/integration/mozilla-inbound/rev/4e6a5f77ef94e26e74a19268b0c8b69bb39d3b55
Bug 823483 patch 5 - Make (again) percentage width on text inputs make intrinsic minimum width be 0.  r=dholbert

https://hg.mozilla.org/integration/mozilla-inbound/rev/623934e9db8ab60eb605fba84e03e882651e8f02
Bug 823483 patch 6 - Tests  r=dholbert
David, Daniel, 
once you have done the review dance, I volunteer to go through all sites with the issues and see how we fix (and hopefully not break things).

Thanks a lot. <3

Comment 64

2 years ago
There are still problems in Flexbox. http://gtms02.alicdn.com/tps/i2/TB1m3hYLFXXXXccXpXXZaUa.pXX-801-475.png
(In reply to percyley from comment #64)
> There are still problems in Flexbox.

I'm pretty sure that's bug 1030952, not this bug.

Comment 66

2 years ago
It seems that bug 1227140 is also not related to this.

Comment 67

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/ee0ff2c8be1b
https://hg.mozilla.org/mozilla-central/rev/3705a4614be0
https://hg.mozilla.org/mozilla-central/rev/d68daa674f40
https://hg.mozilla.org/mozilla-central/rev/b34ebd7afb78
https://hg.mozilla.org/mozilla-central/rev/4e6a5f77ef94
https://hg.mozilla.org/mozilla-central/rev/623934e9db8a
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox47: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
(Assignee)

Comment 68

2 years ago
Comment on attachment 8713919 [details]
MozReview Request: Bug 823483 patch 1 - Check for percentage max-width in addition to percentage width when deciding to ignore intrinsic min-width of replaced elements.  r?dholbert

Approval Request Comment for all 6 patches
[Feature/regressing bug #]: none
[User impact if declined]: bad layout on Web pages; this is a high-priority Web compatibility fix
[Describe test coverage new/current, TreeHerder]: a few reftests in the tree
[Risks and why]: I think the changes are relatively low risk since they change our behavior in a way that moves us closer to other browsers.  However, there's always some risk in changing behavior.  In this case, however, the changes seem likely to help.
[String/UUID change made/needed]: no
Attachment #8713919 - Flags: approval-mozilla-aurora?
(Assignee)

Updated

2 years ago
Attachment #8713920 - Flags: approval-mozilla-aurora?
(Assignee)

Updated

2 years ago
Attachment #8713921 - Flags: approval-mozilla-aurora?
(Assignee)

Updated

2 years ago
Attachment #8713922 - Flags: approval-mozilla-aurora?
(Assignee)

Updated

2 years ago
Attachment #8713923 - Flags: approval-mozilla-aurora?
(Assignee)

Updated

2 years ago
Attachment #8713924 - Flags: approval-mozilla-aurora?
Comment on attachment 8713919 [details]
MozReview Request: Bug 823483 patch 1 - Check for percentage max-width in addition to percentage width when deciding to ignore intrinsic min-width of replaced elements.  r?dholbert

Improves web compatibility, please uplift to aurora.
Attachment #8713919 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #8713920 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #8713921 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #8713922 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #8713923 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #8713924 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 70

2 years ago
remote:   https://hg.mozilla.org/releases/mozilla-aurora/rev/f8ad0bef38d6
remote:   https://hg.mozilla.org/releases/mozilla-aurora/rev/73e66a157d15
remote:   https://hg.mozilla.org/releases/mozilla-aurora/rev/cfb6ca152f13
remote:   https://hg.mozilla.org/releases/mozilla-aurora/rev/99f5f3c0aefa
remote:   https://hg.mozilla.org/releases/mozilla-aurora/rev/95344ff9a45a
remote:   https://hg.mozilla.org/releases/mozilla-aurora/rev/6fc57d89e3fe
status-firefox46: --- → fixed

Updated

2 years ago
Blocks: 1060131
(Assignee)

Updated

2 years ago
Blocks: 1244192
(Assignee)

Updated

2 years ago
Blocks: 975632
(Assignee)

Updated

2 years ago
Blocks: 980432
(Assignee)

Updated

2 years ago
No longer blocks: 1095359

Updated

2 years ago
status-firefox44: --- → affected
status-firefox45: --- → affected
status-firefox46: fixed → verified
status-firefox47: fixed → verified

Updated

2 years ago
Depends on: 1247929
Blocks: 822285
(Assignee)

Updated

2 years ago
Depends on: 1247897
Depends on: 1248174

Updated

2 years ago
Depends on: 1248749
Duplicate of this bug: 1285906

Updated

11 months ago
Blocks: 1308929

Updated

2 months ago
Depends on: 1377440
(Assignee)

Updated

14 days ago
Depends on: 1388840
You need to log in before you can comment on or make changes to this bug.