Closed Bug 1375332 Opened 7 years ago Closed 7 years ago

stylo: font-size doesn't always respond to language-specific minimum size when using charset-derived language

Categories

(Core :: CSS Parsing and Computation, enhancement, P2)

Product:
Core
Component:
CSS Parsing and Computation
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla57
Tracking Flags:
Tracking Status
firefox57 --- fixed

People

(Reporter: xidorn, Assigned: chenpighead)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Bug 1375332 - stylo: move minimum font size applying into the default constructor of nsStyleFont.
59 bytes, text/x-review-board-request
emilio
: review+
Details
Bug 1375332 - stylo: force restyle descendants after character set is updated.
59 bytes, text/x-review-board-request
Details 
This may be the reason of failure in layout/base/tests/test_bug687297.html.

To reproduce this issue:
1. setting font.minimum-size.ja to something large, e.g. 120
2. save the following content to an HTML file and open it:
<!DOCTYPE HTML>
<meta charset="Shift_JIS">
ABCDEFG 0123456

It should use the minimum font size for Japanese, which is set to 120 in the first step, however, it shows as if there is no such setting with Stylo.

When the page grows more complicated, the triggering condition could be more tricky. The test itself fails in some very specific condition, which is not completely clear to me. But I'm guessing if we have the simplified case fixed, the test may be fixed as well.
font-size related. Manish, do you have any idea what's happening here?
Flags: needinfo?(manishearth)
It seems if there is any rule applied on the element, it generally would get the language-specific minimum size applied.
Where does the charset set the language?

It seems like the default font prefs do work for this, so the charset *is* setting the language somehow, it's just the min size stuff that doesn't work.  hm.
Flags: needinfo?(manishearth)
Priority: -- → P2
I can confirm this issue still remains. I'll investigate today.
Assignee: nobody → jeremychen
Status: NEW → ASSIGNED
In Gecko, like Bug 163785, we read prefs and set the minimum font-size while calling SetDefaultOnRoot [1]. However, it seems we don't have that kind of mechanism in Stylo.

One possible solution is to put the same logic like [1] into our font style initialization steps in Stylo. However, it seems that we just call Gecko_Construct_Default_nsStyleFont to use the default constructor of nsStyleFont [2] to construct/initialize the style data for us. Not sure if there's any other place that I could put this logic.

Another solution could be put the logic [1] into nsStyleFont's default constructor [2]. If we go this way, then we should make Stylo case to be thread safe. (maybe put some code pattern like [3] in nsStyleFont's default constructor ) This definitely complicates the code a bit.


[1] https://searchfox.org/mozilla-central/rev/30a47c4339bd397b937abdb2305f99d3bb537ba6/layout/style/nsRuleNode.cpp#2842-2852
[2] https://searchfox.org/mozilla-central/rev/30a47c4339bd397b937abdb2305f99d3bb537ba6/layout/style/nsStyleStruct.cpp#138-143
[3] https://searchfox.org/mozilla-central/rev/30a47c4339bd397b937abdb2305f99d3bb537ba6/layout/style/ServoBindings.cpp#95
See Also: → 163785
Try to add font-size property to the testcase in comment 0, then the minimum font-size pref works fine. The reason is that we do call fixup_font_min_size() in glue codes for font-size property.


[1] https://searchfox.org/mozilla-central/rev/30a47c4339bd397b937abdb2305f99d3bb537ba6/servo/components/style/properties/gecko.mako.rs#2265
Comment on attachment 8894368 [details]
Bug 1375332 - stylo: move minimum font size applying into the default constructor of nsStyleFont.

This patch could read prefs and set default font size correctly. However, it still fails test_bug687297.html. We should use font prefs in a per-document way, and I suspect the CharSet is not updated correctly.... :(
Comment on attachment 8894368 [details]
Bug 1375332 - stylo: move minimum font size applying into the default constructor of nsStyleFont.

Hi Cameron, before going forward, I'd like to have your feedback first.

1. In the current WIP, we call cascade_initial_font_size(context) for all the properties, and I suspect this may hurt our performance. Do you have any idea to do this in somewhere else? Not sure if we have something like initialization steps for document in Stylo, and it seems to me cascading is the first step that we initialize all the style data by copying the results from the style data's constructors in Gecko.

2. This WIP doesn't get test_bug687297.html pass, I thought it is because CharSet is not updated correctly. However, it seems that the updating code path stays purely in Gecko [1]. Now I'm a bit lost... it seems to me CharSet is per document, and we do update CharSet for the document's PresContext [1], and we create/initialize style data according to the PresContext. Any idea about what could possibly go wrong?


[1] https://searchfox.org/mozilla-central/rev/b52285fffc13f36eca6b47de735d4e4403b3859e/layout/base/nsPresContext.cpp#1019
Attachment #8894368 - Flags: feedback?
(In reply to Jeremy Chen [:jeremychen] UTC+8 from comment #11)
> 1. In the current WIP, we call cascade_initial_font_size(context) for all
> the properties, and I suspect this may hurt our performance. Do you have any
> idea to do this in somewhere else? Not sure if we have something like
> initialization steps for document in Stylo, and it seems to me cascading is
> the first step that we initialize all the style data by copying the results
> from the style data's constructors in Gecko.

Yeah, I don't think we should be doing that for all properties like that.  I remember we discussed doing the work that 
nsRuleNode::SetDefaultOnRoot does, adjusting the font-size for the minimum value, at the time we create the initial Gecko structs here:

  http://searchfox.org/mozilla-central/rev/b52285fffc13f36eca6b47de735d4e4403b3859e/servo/components/style/properties/gecko.mako.rs#1025-1032

Did you try that, and did it worK?

> 2. This WIP doesn't get test_bug687297.html pass, I thought it is because
> CharSet is not updated correctly. However, it seems that the updating code
> path stays purely in Gecko [1]. Now I'm a bit lost... it seems to me CharSet
> is per document, and we do update CharSet for the document's PresContext
> [1], and we create/initialize style data according to the PresContext. Any
> idea about what could possibly go wrong?

I'm not sure.  When the charset changes, we should get into nsPresContext::DoChangeCharSet, and the RebuildAllStyleData call there should cause us to recreate the initial style structs (and restyle everything).
(In reply to Cameron McCormack (:heycam) from comment #12)
> (In reply to Jeremy Chen [:jeremychen] UTC+8 from comment #11)
> > 1. In the current WIP, we call cascade_initial_font_size(context) for all
> > the properties, and I suspect this may hurt our performance. Do you have any
> > idea to do this in somewhere else? Not sure if we have something like
> > initialization steps for document in Stylo, and it seems to me cascading is
> > the first step that we initialize all the style data by copying the results
> > from the style data's constructors in Gecko.
> 
> Yeah, I don't think we should be doing that for all properties like that.  I
> remember we discussed doing the work that 
> nsRuleNode::SetDefaultOnRoot does, adjusting the font-size for the minimum
> value, at the time we create the initial Gecko structs here:
> 
>  
> http://searchfox.org/mozilla-central/rev/
> b52285fffc13f36eca6b47de735d4e4403b3859e/servo/components/style/properties/
> gecko.mako.rs#1025-1032
> 
> Did you try that, and did it worK?

Per discussion on IRC, I've fix the patch accordingly, and it works!!

> > 2. This WIP doesn't get test_bug687297.html pass, I thought it is because
> > CharSet is not updated correctly. However, it seems that the updating code
> > path stays purely in Gecko [1]. Now I'm a bit lost... it seems to me CharSet
> > is per document, and we do update CharSet for the document's PresContext
> > [1], and we create/initialize style data according to the PresContext. Any
> > idea about what could possibly go wrong?
> 
> I'm not sure.  When the charset changes, we should get into
> nsPresContext::DoChangeCharSet, and the RebuildAllStyleData call there
> should cause us to recreate the initial style structs (and restyle
> everything).

Hmm... with the latest version of WIP, the test still isn't passed. Not sure if we could land the fix first, then investigate the test failure as a followup? What do you think, Cameron? Either land the fix first or not, I think the current patch is doing the right thing, and it is ready for review.
Attachment #8894368 - Flags: review?(cam)
Comment on attachment 8894368 [details]
Bug 1375332 - stylo: move minimum font size applying into the default constructor of nsStyleFont.

https://reviewboard.mozilla.org/r/165538/#review171000

I think this patch is right, although I can't say why the test is not passing.  I think we should work out why it's not passing before landing this, in case it turns out we should be taking a different approach.

::: servo/components/style/properties/gecko.mako.rs:1030
(Diff revision 2)
>      pub fn default(pres_context: RawGeckoPresContextBorrowed) -> Arc<Self> {
>          let mut result = Arc::new(${style_struct.gecko_struct_name} { gecko: unsafe { zeroed() } });
>          unsafe {
>              Gecko_Construct_Default_${style_struct.gecko_ffi_name}(&mut Arc::get_mut(&mut result).unwrap().gecko,
>                                                                     pres_context);
> +            // Read font related user prefs to initialize the default font size.

Nit: put this comment inside the `% if`, so that if you look at the generated gecko_properties.rs the comment won't appear in every style struct's default() function.

::: servo/components/style/properties/gecko.mako.rs:1031
(Diff revision 2)
>          let mut result = Arc::new(${style_struct.gecko_struct_name} { gecko: unsafe { zeroed() } });
>          unsafe {
>              Gecko_Construct_Default_${style_struct.gecko_ffi_name}(&mut Arc::get_mut(&mut result).unwrap().gecko,
>                                                                     pres_context);
> +            // Read font related user prefs to initialize the default font size.
> +            % if style_struct.gecko_struct_name == "nsStyleFont":

Or just `if style_struct.name == "Font"`

::: servo/components/style/properties/gecko.mako.rs:1033
(Diff revision 2)
> +                Gecko_nsStyleFont_FixupMinFontSize(&mut Arc::get_mut(&mut result).unwrap().gecko,
> +                                                   pres_context);

I'm pretty sure we are always on the main thread in here, which means we don't really need the locking that Gecko_nsStyleFont_FixupMinFontSize, but since we don't create these initial structs often I think it doesn't matter.

(Also I see that nsRuleNode::ApplyMinFontSize, which Gecko_nsStyleFont_FixupMinFontSize calls, does slightly different things from the fixups in nsRuleNode::SetDefaultOnRoot, in that it also looks at mMinFontSizeRatio.  But the default constructed nsStyleFont just has that value at 100 so we don't need to worry about that.)
Comment on attachment 8894368 [details]
Bug 1375332 - stylo: move minimum font size applying into the default constructor of nsStyleFont.

https://reviewboard.mozilla.org/r/165538/#review171000

yeah, to clarify the uncertainty before landing does make sense. I'll keep digging.

> Nit: put this comment inside the `% if`, so that if you look at the generated gecko_properties.rs the comment won't appear in every style struct's default() function.

Will do.

> Or just `if style_struct.name == "Font"`

Will do.

> I'm pretty sure we are always on the main thread in here, which means we don't really need the locking that Gecko_nsStyleFont_FixupMinFontSize, but since we don't create these initial structs often I think it doesn't matter.
> 
> (Also I see that nsRuleNode::ApplyMinFontSize, which Gecko_nsStyleFont_FixupMinFontSize calls, does slightly different things from the fixups in nsRuleNode::SetDefaultOnRoot, in that it also looks at mMinFontSizeRatio.  But the default constructed nsStyleFont just has that value at 100 so we don't need to worry about that.)

Yeah, there's a slight difference. And as you commented, we shall be fine doing this way. Thanks. :)
Okay, I re-read the test_bug687297.html carefully, and it seems that all the test files, bug687297_{a, b, c}.html, have a universal style that sets "font-size: 9px;". I'm afraid that the hypothesis that I've made about "solving testcase in comment 0 can fix the test_bug687297.html test" might be wrong. These test files should be rendered correctly even without the fix, cause we do call Gecko_nsStyleFont_FixupMinFontSize while processing font-size property [1] in Stylo.

I thought about the sync/asyc restyle mechanism in Gecko/Servo, so I tried adding some setTimeout in the tests, but the rendering result is still not correct.

I added couple logs to monitor the test, and it appears that the Gecko_nsStyleFont_FixupMinFontSize is indeed called for each of the three documents, and the minFontSize is referred to set font size correctly in nsRuleNode::ApplyMinFontSize [2]. I'll keep digging to see why the rendering result doesn't match the value that we set in nsRuleNode::ApplyMinFontSize.



[1] https://searchfox.org/mozilla-central/rev/bd39b6170f04afeefc751a23bb04e18bbd10352b/servo/components/style/properties/gecko.mako.rs#2272-2288
[2] https://searchfox.org/mozilla-central/rev/bd39b6170f04afeefc751a23bb04e18bbd10352b/layout/style/nsRuleNode.cpp#469
(In reply to Jeremy Chen [:jeremychen] UTC+8 from comment #18)
> Okay, I re-read the test_bug687297.html carefully, and it seems that all the
> test files, bug687297_{a, b, c}.html, have a universal style that sets
> "font-size: 9px;". I'm afraid that the hypothesis that I've made about
> "solving testcase in comment 0 can fix the test_bug687297.html test" might
> be wrong. These test files should be rendered correctly even without the
> fix, cause we do call Gecko_nsStyleFont_FixupMinFontSize while processing
> font-size property [1] in Stylo.

No, I was wrong. With or without the fix, rendering result of bug687297_b.html is always wrong in Stylo. The interesting part is, if we remove all the scripts (between <script> and </script>) in bug687297_b.html, the rendering result is correct.
Finally, I got a little progress with rr...

Looks like both cases (w/ or w/o <script> element) would get into here [1] during frame construction. Since this timing is during frame construction, calling aPresContext->GetContentLanguage() to get content language from document [2] should always return NULL (in our case), then lead us to fallback to use document's charset [3]. However, w/ <script> element, somewhat we get "x-western" from the charset, which lead us NOT to use "ja" specified in the test page.


[1] https://searchfox.org/mozilla-central/rev/e8c36327cd8c9432c69e5e1383156a74330f11f2/layout/base/nsPresContext.cpp#2038
[2] https://searchfox.org/mozilla-central/rev/e8c36327cd8c9432c69e5e1383156a74330f11f2/layout/style/nsStyleStruct.cpp#229
[3] https://searchfox.org/mozilla-central/rev/e8c36327cd8c9432c69e5e1383156a74330f11f2/layout/style/nsStyleStruct.cpp#236
The second patch is the one that really make the test pass. I just checked on my local, and still wait for a positive try result. Since the first patch is the right thing to do, I think we should just land them together in this bug.
Attachment #8894368 - Flags: review?(cam)
Attachment #8899424 - Flags: review?(cam)
Following is the timeline of the usual flow with a simple test page like comment 0: 

1. Init document with default character set [1], which is WINDOWS_1252_ENCODING
2. nsPresContext->mLanguage [2][3] is then resolved to "x-western" (on Mac)
3. DoChangeCharSet() runnable is scheduled to update the character set to "Shift_JIS"
4. nsPresContext->mLanguage [2][3] is then resolved to "ja"

Here's the issue, in Stylo, if our document contains one (or more) <script> elements, the last time we construct frames is always a bit earlier than step 3. So, the document CharSet/Language is updated, but the style data is always out-of-date. (Try the testcase in comment 0 with an empty <script> element, the result is wrong at first, but can be correct if you open the inspector to force a restyle)

However, if we remove all the <script> elements, we can guarantee that the last time we construct frames is always after step 4. So, the style data is up-to-date.

Though I haven't checked if the last time frames construction is triggered by the initial frame construction or a reconstruction frame restyle...

I'm fixing this by sending eRestyle_ForceDescendants hint to force an extra restyle once we update the character set (see the 2nd patch). I don't think dynamically updating character sets is an usual case, so the extra cost (though could be avoidable) might be fine.

Not sure what's the difference of the frame construction/reconstruction between Gecko and Stylo, but Gecko seems pretty consistent no matter the document has <script> elements or not...

Hi Emilio, Cameron told me that you might be interested in this timing issue, since you are/were working at some frame construction stuff.



[1] https://searchfox.org/mozilla-central/rev/b258e6864ee3e809d40982bc5d0d5aff66a20780/dom/base/nsDocument.cpp#1297
[2] https://searchfox.org/mozilla-central/rev/b258e6864ee3e809d40982bc5d0d5aff66a20780/layout/base/nsPresContext.cpp#1019
[3] https://searchfox.org/mozilla-central/rev/b258e6864ee3e809d40982bc5d0d5aff66a20780/layout/base/nsPresContext.cpp#1090
[4] https://searchfox.org/mozilla-central/rev/b258e6864ee3e809d40982bc5d0d5aff66a20780/layout/base/nsPresContext.cpp#1080
Flags: needinfo?(emilio+bugs)
Oops, the reference [4] is supposed to be put right after the DoChangeCharSet() in the step 3.
(In reply to Jeremy Chen [:jeremychen] UTC+8 from comment #25)
> Not sure what's the difference of the frame construction/reconstruction
> between Gecko and Stylo, but Gecko seems pretty consistent no matter the
> document has <script> elements or not...

Gecko rebuilds the rule tree on RebuildAllStyleData, so it seems to me that it'll recompute all the style structs, is that right Cameron?

If so, the ForceDescendants bit sounds fine to me.
Flags: needinfo?(emilio+bugs)
Yes, the ForceDescendants change sounds like the correct change to me.

I think the thing Jeremy wants to bring to your attention though is that there seems to be a difference between Stylo and Gecko in terms of when the charset updating runnable runs versus the first time we construct frames, and that for documents with <script> elements (or whatever else might happen to cause frames to get constructed relatively early), we could be wastefully restyling because we haven't properly set the charset yet.  (And perhaps we should be able to know what the charset is by that point.)

I think it's OK for now just to ensure that the charset-updating does the restyle correctly, but we probably want to see if we can avoid this additional restyle.  (And maybe understand why this doesn't happen in Gecko.)
(In reply to Cameron McCormack (:heycam) from comment #28)
> Yes, the ForceDescendants change sounds like the correct change to me.
> 
> I think the thing Jeremy wants to bring to your attention though is that
> there seems to be a difference between Stylo and Gecko in terms of when the
> charset updating runnable runs versus the first time we construct frames,
> and that for documents with <script> elements (or whatever else might happen
> to cause frames to get constructed relatively early), we could be wastefully
> restyling because we haven't properly set the charset yet.  (And perhaps we
> should be able to know what the charset is by that point.)
> 
> I think it's OK for now just to ensure that the charset-updating does the
> restyle correctly, but we probably want to see if we can avoid this
> additional restyle.  (And maybe understand why this doesn't happen in Gecko.)

What I was trying to say is that in Gecko the ForceDescendants happens already, to some extent, because of RebuildAllStyleData reconstructing the thing, so I think that is just wallpapering the bug on Gecko.

It's normal that <script> changes the time frame construction happens, afaict. I suspect the HTML parser sends content in a different way when it finds a <script> tag vs. when it doesn't.
(In reply to Emilio Cobos Álvarez [:emilio] from comment #29)
> (In reply to Cameron McCormack (:heycam) from comment #28)
> > Yes, the ForceDescendants change sounds like the correct change to me.
> > 
> > I think the thing Jeremy wants to bring to your attention though is that
> > there seems to be a difference between Stylo and Gecko in terms of when the
> > charset updating runnable runs versus the first time we construct frames,
> > and that for documents with <script> elements (or whatever else might happen
> > to cause frames to get constructed relatively early), we could be wastefully
> > restyling because we haven't properly set the charset yet.  (And perhaps we
> > should be able to know what the charset is by that point.)
> > 
> > I think it's OK for now just to ensure that the charset-updating does the
> > restyle correctly, but we probably want to see if we can avoid this
> > additional restyle.  (And maybe understand why this doesn't happen in Gecko.)
> 
> What I was trying to say is that in Gecko the ForceDescendants happens
> already, to some extent, because of RebuildAllStyleData reconstructing the
> thing, so I think that is just wallpapering the bug on Gecko.
> 
> It's normal that <script> changes the time frame construction happens,
> afaict. I suspect the HTML parser sends content in a different way when it
> finds a <script> tag vs. when it doesn't.

So, Gecko already handles ForceDescendants in RebuildAllStyleData, maybe the call of FlushPendingNotifications in [1]? In Stylo, we implement RebuildAllStyleData very differently, so this ForceDescendants is probably needed to make the behavior match Gecko. Is that correct?


[1] https://searchfox.org/mozilla-central/rev/b258e6864ee3e809d40982bc5d0d5aff66a20780/layout/base/GeckoRestyleManager.cpp#447
I think the patches are ready for review (based on comment 27 and comment 28). The comments might need a bit tweak though.
See Also: → 1391341
Comment on attachment 8894368 [details]
Bug 1375332 - stylo: move minimum font size applying into the default constructor of nsStyleFont.

Balancing some workload.
Attachment #8894368 - Flags: review?(cam) → review?(emilio+bugs)
Attachment #8899424 - Flags: review?(cam) → review?(emilio+bugs)
Comment on attachment 8894368 [details]
Bug 1375332 - stylo: move minimum font size applying into the default constructor of nsStyleFont.

https://reviewboard.mozilla.org/r/165538/#review176702

::: servo/components/style/properties/gecko.mako.rs:1028
(Diff revision 4)
>      pub fn default(pres_context: RawGeckoPresContextBorrowed) -> Arc<Self> {
>          let mut result = Arc::new(${style_struct.gecko_struct_name} { gecko: unsafe { zeroed() } });
>          unsafe {
>              Gecko_Construct_Default_${style_struct.gecko_ffi_name}(&mut Arc::get_mut(&mut result).unwrap().gecko,
>                                                                     pres_context);
> +            % if style_struct.name == "Font":

This look ok, but I wonder why can't this be on the default constructor of `nsStyleFont`? (the one that takes a `nsPresContext`).

Looks like it'd be simpler, avoiding duplication of the Gecko bit too, and avoiding to grab a bunch of locks, given this is main thread only anyway.
Attachment #8894368 - Flags: review?(emilio+bugs)
Comment on attachment 8899424 [details]
Bug 1375332 - stylo: force restyle descendants after character set is updated.

https://reviewboard.mozilla.org/r/170698/#review176704

::: commit-message-50797:3
(Diff revision 2)
> +Bug 1375332 - stylo: force restyle descendants after character set is updated.
> +
> +In Stylo, if there exists one or more <script> elements in the document, frames

nit: frame construction

But the underlying reason AIUI is that gecko does this implicitly anyway.

::: layout/base/nsPresContext.cpp:1091
(Diff revision 2)
> +  // restyle descendants to make their style data up-to-date. This could be
> +  // avoidable if we can find a way to guarantee that frame construction is
> +  // always after UpdateCharSet(). In that case, we should be able to use the
> +  // same restyle hint as Gecko does, and save the cost of the post restyling.
> +  RebuildAllStyleData(NS_STYLE_HINT_REFLOW,
> +                      mShell && mShell->StyleSet()->IsServo()

nit: What about using `mDocument->IsStyledByServo` instead? That way you don't need to do a null-check that looks slightly fishy.

I think moving the restyle hint to a different variable will make it a bit more readable, but it's not a big deal.
Attachment #8899424 - Flags: review?(emilio+bugs) → review+
Comment on attachment 8899424 [details]
Bug 1375332 - stylo: force restyle descendants after character set is updated.

https://reviewboard.mozilla.org/r/170698/#review176708
Comment on attachment 8894368 [details]
Bug 1375332 - stylo: move minimum font size applying into the default constructor of nsStyleFont.

https://reviewboard.mozilla.org/r/165538/#review176702

> This look ok, but I wonder why can't this be on the default constructor of `nsStyleFont`? (the one that takes a `nsPresContext`).
> 
> Looks like it'd be simpler, avoiding duplication of the Gecko bit too, and avoiding to grab a bunch of locks, given this is main thread only anyway.

I did thought about this solution. At that time, I thought I have to implement the locks in the default constructor of nsStyleFont to make it work for Stylo, which definitely complicates the code, so I gave up. Since this is main thread only, then no locks need to be implemented and we shall be fine.

I'll fix this in the next version.
Attachment #8894368 - Flags: review?(cam) → review?(emilio+bugs)
Attachment #8894368 - Flags: review?(emilio+bugs)
Attachment #8899424 - Flags: review?(cam)
The sync mechanism between Reviewboard and Bugzilla is sooooo annoying....:(
Comment on attachment 8894368 [details]
Bug 1375332 - stylo: move minimum font size applying into the default constructor of nsStyleFont.

https://reviewboard.mozilla.org/r/165538/#review176738

::: layout/style/nsStyleStruct.cpp:153
(Diff revision 5)
>  
>  nsStyleFont::nsStyleFont(const nsPresContext* aContext)
>    : nsStyleFont(*aContext->GetDefaultFont(kPresContext_DefaultVariableFont_ID,
>                                            nullptr),
>                  aContext)
>  {

Let's `MOZ_ASSERT(NS_IsMainThread())` here.
Attachment #8894368 - Flags: review+
Pushed by jichen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/665197f96a9b
stylo: move minimum font size applying into the default constructor of nsStyleFont. r=emilio
https://hg.mozilla.org/integration/autoland/rev/716ca00ed476
stylo: force restyle descendants after character set is updated. r=emilio
https://hg.mozilla.org/mozilla-central/rev/665197f96a9b
https://hg.mozilla.org/mozilla-central/rev/716ca00ed476
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: