Closed Bug 1690235 Opened 3 years ago Closed 3 years ago

Wrong Unicode characters on Greek letters on print to pdf , after 84.00 update

Categories

(Core :: Printing: Output, defect, P2)

Product:
Core
Component:
Printing: Output
Version:
Firefox 85
Platform:
Unspecified
macOS
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
87 Branch
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox85 --- wontfix
firefox86 --- verified
firefox87 --- verified

People

(Reporter: vagvalas, Assigned: jfkthame)

References

(Regression,
URL
)

Details

(Keywords: regression)

Attachments

(4 files)

FF bug.jpg
1.10 MB, image/jpeg
Details
Bug 1690235 - Don't use a font descriptor for variation fonts on systems before macOS 10.15. r=lsalzman
48 bytes, text/x-phabricator-request
pascalc
: approval-mozilla-beta+
Details | Review
Bug 1690235. Fix creating variation CTFonts.
48 bytes, text/x-phabricator-request
pascalc
: approval-mozilla-beta+
Details | Review
testcase for variations of macOS system font
1.32 KB, text/html
Details
Attached image FF bug.jpg —

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

I was work for my government posting applies to this website: https://voucher.gov.gr/ui/project/37/personal

When an apply is completed i printed on pdf to save locally.
This was fine till Firefox update 85.00 ( i jumped from 83.00 to 85.00, i don't know why. but i can reproduce it even on 84.00.

Actual results:

When i tried to save as pdf, the character encoding of upper part of page (i think its header) you should defently see the exact same page to found out why ( https://voucher.gov.gr/ui/project/37/personal ) is appear with squares and the characters is losted, and unavailable.
Also After the updated version for PRINT DIALOG (the new one) the new dialog, is not showed up, if you are updating from old version with old profile. I had to delete the old profile to appear the new dialog, and there is no setting to get the new one, from old one.

Expected results:

On Firefox prior to 84.00: ( on 83.00 for example) this issue is not there ( and the page has not change at all), the save to pdf was working perfectly, and the characters as shown on the image, is perfectly grabbed and saved.
https://voucher.gov.gr/ui/project/37/personal

UPDATE it seems that its there after 82.00 update.
on 81.00 it works fine.
but for some reason one time as i was writing (replacing firefox over and over the other) the 83.00 seemed to work also..
I dont know... but with the clean installation the bug its there from 82.00.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → PDF Viewer
Component: PDF Viewer → Printing: Output
Product: Firefox → Core

After 18-19 installations and un-installations (i figured it out that FF, forces update even on first launch of old updates.. ( thats creepy) (so before i even launch the old version, the new one was already installed, as i had a gigabit connection)....
Any way...
I CAME DOWN TO A CONCLUSION:

That it has something to do with the dialog. The system (mac dialog) and the new one)
As i noticed ( after clean install with new profile , and cutted off the internet connection the FF doesnt seems to "fetch" a request for new PRINT dialog, and it uses the old one.) EVEN on 85.00 i can replicate that, that if i cut the internet connection and hit cmd+P , the print dialog is the old one. And it could at sometime "fetch" the new. (so i assume its some kind of server request.)
And finally to sup up: to conditions:
With the new print dialog, it does the bug at every version of 82.00 and above.. if it hurry and fetch the new dialog you are screwed to bug. (its different if it doesnt fetch at all the new dialog and the way its procces the webpage to make the pdf, than just hitting use the system default dialog.)
With the old dialog and internet connections cutted off so to not use the new one.
I managed to make the pdf perfectly save till (and ) firefox 84.00, on 85.00 i managed to force use the old dialog but the characters its still messy...

Hope for you to have a better image of all..

jfkthame: Do you have any idea what would be causing this issue?

Flags: needinfo?(jfkthame)

I don't really have any ideas at the moment. I tried using Save As PDF with the site from comment 0 and it worked fine for me, both with Firefox 84 and 85, and with Nightly.

@vagvalas: could you please attach a copy of the actual PDF that you get when this problem happens?

Flags: needinfo?(jfkthame) → needinfo?(vagvalas)

(In reply to Jonathan Kew (:jfkthame) from comment #5)

I don't really have any ideas at the moment. I tried using Save As PDF with the site from comment 0 and it worked fine for me, both with Firefox 84 and 85, and with Nightly.

@vagvalas: could you please attach a copy of the actual PDF that you get when this problem happens?

(In reply to Emily McDonough [:alaskanemily] from comment #4)

jfkthame: Do you have any idea what would be causing this issue?

Its also fine on me on Windows 10 machine. Its dedicated to macOS, i tried even on my Hackintosh and got same results as my macbook.

Flags: needinfo?(vagvalas)

But I'm also on macOS, and I don't get the problem here. So I'd be interested to have a look at your file.

(In reply to Jonathan Kew (:jfkthame) from comment #7)

But I'm also on macOS, and I don't get the problem here. So I'd be interested to have a look at your file.

https://cdn.discordapp.com/attachments/779319798336716840/806293582038171670/epitagi.pdf

The affected text seems to be getting assigned to the "LastResort" font in your version of the PDF, whereas for me it appears in the macOS system font ".SF NS".

I think this might have something to do with the optical-sizing feature in the font. If you go to about:config and find the setting layout.css.font-variations.enabled, and double-click to set it to false, and then reload the browser, does that make any difference to the result you get?

(In reply to Jonathan Kew (:jfkthame) from comment #10)

The affected text seems to be getting assigned to the "LastResort" font in your version of the PDF, whereas for me it appears in the macOS system font ".SF NS".

I think this might have something to do with the optical-sizing feature in the font. If you go to about:config and find the setting layout.css.font-variations.enabled, and double-click to set it to false, and then reload the browser, does that make any difference to the result you get?

Tell me your Paypal to buy you a beer!!! Bro you are a life saver!!! It worked! Tested twice!
So what was ""wrong""..??

(In reply to vagvalas from comment #11)

(In reply to Jonathan Kew (:jfkthame) from comment #10)

The affected text seems to be getting assigned to the "LastResort" font in your version of the PDF, whereas for me it appears in the macOS system font ".SF NS".

I think this might have something to do with the optical-sizing feature in the font. If you go to about:config and find the setting layout.css.font-variations.enabled, and double-click to set it to false, and then reload the browser, does that make any difference to the result you get?

Tell me your Paypal to buy you a beer!!! Bro you are a life saver!!! It worked! Tested twice!
So what was ""wrong""..??

So.. Its just a font issue? https://github.com/unicode-org/last-resort-font . If i install the font it will be okay? How you didnt have this issue on your MacOS, FF 85.0? Do you have the font installed?
Here its referring that the font requires the:
""The latest pre-built binary version of the Last Resort font, which corresponds to "Unicode Version 13.0.0", can be easily downloaded from the Latest Release. This font may be updated for future versions of the Unicode Standard as time and resources permit.""
Does mojave (that i had installed support unicode 13.00?) as i saw it released on March 2020 the unicode 13.00, and as i know from iOS that i have jailbreak, the emoji tweak, need ios 14 to install emojies that requires unicode 13.00. So maybe i need catalina for Unicode 13.00?

"Smiling Face with Tear was approved as part of Unicode 13.0 in 2020 and added to Emoji 13.0 in 2020. " From apple.

also its system wide as even the acrobat pro that i have installed having troubles to handle those characters, and even cant let me edit them.
https://drive.google.com/file/d/1lu07ZD10x61QvL25AZORMRY9If7j4Qtv/view?usp=sharing

So what can i do?
could you please explain to me with your thoughts the issue?

It even dont know the character to install them
https://ibb.co/bB46yrP

no... no i got.. The last resort is a glyph font... so my system doesn't know the original first font, and dispays them as last resort font, which is a glyph font..
So how can i install the original font?

https://ibb.co/xXWVBdN

Forget about installing a "LastResort" font, that's not going to help you. (Actually, there is already a version of this present in macOS, but it's hidden in the system, not shown in the menus or Font Book or anything.)

The problem seems to be with the macOS system font "SF NS", which is now a "variation font" where instead of separate fonts for regular, bold, and so on (also for different "optical sizes"), there's a single font that can adjust its display to different weights. So when you see some regular and some bold text at the top of that page, it's actually the exact same font, with a different "weight" setting applied. (On an older system, there would have been two separate "faces".)

That's all fine when you view the page in Firefox, but when you print (or Save As PDF), the details of the variation font are getting lost so that it doesn't know what font it should be using, and ends up drawing the "LastResort" boxes instead. I don't think there's anything you can do to solve this (except for disabling the variation, with that about:config setting -- but this means the bold text doesn't look as good as it should). We need to figure out where the font details are getting confused within Firefox, and fix that.

One complication is that Apple keeps changing this stuff in each macOS version; I'm running version 11.1beta (Big Sur), and that's probably why it doesn't happen for me. But if this is a problem for everyone on 10.14, that's pretty serious and we should try to find a solution.

Okay i got about the FF part and all the variations and why is happening.

I want to give you two more hints that now leads the problem to actually something in macOS system and not FF ( i think):
Could you investigate it more now?
Firstly:
As it seems when try to edit pdf with acrobat, (that genareted with firefox) even on fields that seemed okay, (when i just copy it, its okay,) when i tryied to edit the field, and then copy it Acrobat PRO still has the issue about that certain font. So that font somehow is missing, is a variant or else in macOS system..
1.
https://drive.google.com/file/d/1LYp26n-NqsTdyN54JXmg978FUDCTEW8e/view?usp=sharing

and secondly: (as i couldnt step back to work) i used Google Chrome to generate pdfs.:
And as you can see even it "looks" okay that the chrome variated and generated the pdf well, the actuall macOS system still doesnt know the variant of the correct generated field (if it was correct).. So maybe 10.14 has some troubles with SFNS?
2.
https://drive.google.com/file/d/1jpuuUUMNTi_nqffzydGVD7mRxNO9jxES/view?usp=sharing

Also the .SFNS is the San Fransisco?

Thank you.

.SFNS is an internal version of San Francisco that macOS uses as the "system font"; it doesn't normally show up in applications (font menus and so on), but websites can use it by requesting in CSS font-family: -apple-system (for Firefox/Safari) or font-family: BlinkMacSystemFont (for Chrome). But there seem to be issues with including this special font in PDFs... Firefox tries to use it, but fails, while I think Chrome probably creates its own internal version, which works, but then Acrobat can't find it if you try to modify the PDF.

What happens if you use Safari and save this page as PDF from there?

(In reply to Jonathan Kew (:jfkthame) from comment #18)

.SFNS is an internal version of San Francisco that macOS uses as the "system font"; it doesn't normally show up in applications (font menus and so on), but websites can use it by requesting in CSS font-family: -apple-system (for Firefox/Safari) or font-family: BlinkMacSystemFont (for Chrome). But there seem to be issues with including this special font in PDFs... Firefox tries to use it, but fails, while I think Chrome probably creates its own internal version, which works, but then Acrobat can't find it if you try to modify the PDF.

What happens if you use Safari and save this page as PDF from there?

Same behaviour as chrome. It saves perfectly, and letters are exactly bold. So im assume it does the variation. But again the Acrobat Pro DC struggles to find the font, and prompts the same message about font ".SFNSText or .SFNSDisplay"!

I have managed to reproduce this issue using the following:

  • macOS 10.14
  • macOS 10.13

This issue doesn't seem to be reproducible on:

  • macOS 10.12
  • macOS 10.15
  • macOS 11.1

I can reproduce this issue using both the old & new UI on:

  • Firefox 87.0a1 (BuildId:20210203093146)
  • Firefox 86.0b5 (BuildId:20210202185823)
  • Firefox 85.0 (BuildId:20210118153634)

I can't reproduce this issue on both new & old UI using Firefox 84.0 (BuildId:20201211215739)...

This issue seems to be a regression:
27:04.05 INFO: Last good revision: b6f443ea3543857e8602827ac5ebe35eb14dfecf
27:04.05 INFO: First bad revision: 42b9dbf35ce82a25588d9d4652635a4634f1d61e
27:04.05 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b6f443ea3543857e8602827ac5ebe35eb14dfecf&tochange=42b9dbf35ce82a25588d9d4652635a4634f1d61e

  • Potential regressor: Bug 1625590 (performed the regression search twice)

Additional notes:
I can confirm that setting layout.css.font-variations.enabled to false fixes this behavior.

URL: https://voucher.gov.gr/ui/project/37/...
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
status-firefox85: --- → affected
status-firefox86: --- → affected
status-firefox87: --- → affected
Ever confirmed: true
Keywords: regression
OS: Unspecified → macOS
Regressed by: 1625590
Severity: -- → S2
Priority: -- → P2
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/efa3315a601b
Don't use a font descriptor for variation fonts on systems before macOS 10.15. r=lsalzman

https://hg.mozilla.org/mozilla-central/rev/efa3315a601b

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox87: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch

Comment on attachment 9200910 [details]
Bug 1690235 - Don't use a font descriptor for variation fonts on systems before macOS 10.15. r=lsalzman

Beta/Release Uplift Approval Request

  • User impact if declined: Pages that use the macOS system font (or other variable fonts) result in garbage in Save As PDF output (or when printed, probably) for users on macOS 10.13 / 10.14.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: On macOS 10.13 or 10.14, open https://voucher.gov.gr/ui/project/37/personal and save as PDF; then check the resulting PDF file.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): For affected systems, this just reverts to the pre-bug 1625590 behavior to avoid the problem.
  • String changes made/needed: n/a
Attachment #9200910 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]
Regressions: 1690730

Probably we should wait with uplifting until the regression bug 1690730 has been investigated / fixed.

Jonathan, can we uplift this patch if it caused bug 1690730?

Flags: needinfo?(jfkthame)

That's a hard call...

On the one hand, the breakage here (total garbage in printed output for certain content/fonts) is much more severe than the subtle regression in rendering of the system font seen in bug 1690730; but on the other hand, that will presumably be visible to everyone on 10.13 (and possibly 10.14, I'm not sure if it will be affected similarly), whereas the printing issue will only affect a smaller subset of users (people on affected OS versions who attempt to print a document that uses the system font or another installed variable font).

We don't currently have a clear understanding of why the font rendering regression in bug 1690730 occurred, and therefore it's unclear if we will be able to come up with a fix (that doesn't revert this and therefore re-break printing).

On balance, I think I'd say that the printing regression is so much more severe, even though it will affect fewer users, that we should uplift the fix despite bug 1690730; the issue there does not in any way make the browser unusable or the content illegible, it just means the font rendering isn't quite as clear.

(Ideally, we'll also figure out a fix for bug 1690730 and uplift that as well, but we have no assurance this will happen.)

Flags: needinfo?(jfkthame)

This issue is verified fixed using Firefox 87.0a1 (BuildId:20210207214322) on macOS 10.14 & macOS 10.13.

The https://voucher.gov.gr/ui/project/37/personal is displayed without issues while using both save to pdf & physical printer destinations.

status-firefox87: fixed → verified

I'm not a huge fan of this patch because it makes us copy system fonts with WebRender. Perhaps, we could make it only fail GetDescriptor if printing.

It would be nice to better understand what's failing here. WebRender is able to use the font descriptor for variable fonts on 10.13 so it's weird that this is only failing for printing.

I've been able to reproduce it locally so I can take a closer look tomorrow.

(In reply to Jonathan Kew (:jfkthame) from comment #29)

That's a hard call...

On the one hand, the breakage here (total garbage in printed output for certain content/fonts) is much more severe than the subtle regression in rendering of the system font seen in bug 1690730; but on the other hand, that will presumably be visible to everyone on 10.13 (and possibly 10.14, I'm not sure if it will be affected similarly), whereas the printing issue will only affect a smaller subset of users (people on affected OS versions who attempt to print a document that uses the system font or another installed variable font).

We don't currently have a clear understanding of why the font rendering regression in bug 1690730 occurred, and therefore it's unclear if we will be able to come up with a fix (that doesn't revert this and therefore re-break printing).

On balance, I think I'd say that the printing regression is so much more severe, even though it will affect fewer users, that we should uplift the fix despite bug 1690730; the issue there does not in any way make the browser unusable or the content illegible, it just means the font rendering isn't quite as clear.

(Ideally, we'll also figure out a fix for bug 1690730 and uplift that as well, but we have no assurance this will happen.)

Well.. Jonathan to give my opinion of my understanding, i know that my bug is more sever but with a fewer people affected. But if i just can fix that with that "false" value on "css.variations.fonts" etc.. thats okay to me.
If more users is affected with that changed layout of rendering the font and (change so much the background color) i would prefer to revert this bug, and have a look on regression that is referring on the other bug 1690730,
from back the other bug 1625590 , which is been disclosed but its the main reason after 76.0a that this behavior is changed.

I think you should investigate more why the WebRender is failing? and what changed back in 76.00 .
Anyway the decision is already taken in 87.00 as i can, but really. if that just true or false. just leave it there, if the other bug, doesn't have an option to revert it, and only mine's has.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #31)

I'm not a huge fan of this patch because it makes us copy system fonts with WebRender. Perhaps, we could make it only fail GetDescriptor if printing.

It would be nice to better understand what's failing here. WebRender is able to use the font descriptor for variable fonts on 10.13 so it's weird that this is only failing for printing.

I've been able to reproduce it locally so I can take a closer look tomorrow.

thats awesome

(In reply to Jeff Muizelaar [:jrmuizel] from comment #31)

I'm not a huge fan of this patch because it makes us copy system fonts with WebRender. Perhaps, we could make it only fail GetDescriptor if printing.

It would be nice to better understand what's failing here. WebRender is able to use the font descriptor for variable fonts on 10.13 so it's weird that this is only failing for printing.

I've been able to reproduce it locally so I can take a closer look tomorrow.

Agreed, this isn't ideal by any means - it seemed the simplest way to fix the immediate issue, by reverting to behavior that worked in the past, but a better solution (that doesn't involve copying the font data) would be most welcome.

In UnscaledFontMac::CreateFromFontDescriptor, we pass the descriptor to CGFontCreateWithFontName, which I guess must be what fails here. I think what happens with the system font (and potentially other variable fonts, if present) is that we get a synthetic PostScript name as the font descriptor that includes a representation of the current variation settings. But apparently CGFontCreateWithFontName doesn't recognize that, and ends up giving us .LastResort.

If I'm looking at the right place in the rust code, I think what WR does instead is to go through CTFontDescriptorCreateWithNameAndSize (using size=0.0) to get a CTFontDescriptor, and then from that it instantiates a font using CTFontCreateWithFontDescriptor. I guess CTFontDescriptor understands the extended synthetic PSname and maps it to the proper underlying font + variation settings.

So maybe we can do something comparable in UnscaledFontMac, and avoid the problem there.

We'll need to be cautious, though (and test whatever we do across all supported macOS versions), given that we have also had issues with instantiating the macOS system font correctly in webrender, and had to explicitly go through a CGFont-based path to resolve that IIRC. (See bug 1675185.) This stuff is maddeningly fragile, and seems to change with each OS update. :(

Comment on attachment 9200910 [details]
Bug 1690235 - Don't use a font descriptor for variation fonts on systems before macOS 10.15. r=lsalzman

I am going to take this patch in beta, thanks for the hindsight!

Attachment #9200910 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

The following code passes on 10.15 but fails on 10.13

    let mut vals_str: Vec<(CFString, CFNumber)> = Vec::new();
    let small = unsafe {
        CTFont::wrap_under_create_rule(
            CTFontCreateUIFontForLanguage(kCTFontEmphasizedSystemDetailFontType, 19., std::ptr::null())
        )
    };
    let font= small.copy_to_CGFont();
    vals_str.push((CFString::new("Weight"), (700.).into()) );
    let vars = CFDictionary::from_CFType_pairs(&vals_str);
    let var_font = CGFont::create_copy_from_variations(&font, &vars).unwrap();
    let ct_font = new_from_CGFont(&var_font.clone(), 19.);
    assert_ne!(ct_font.family_name(), ".LastResort");

WebRender avoids this problem by always using new_from_CGFont_with_variations instead of new_from_CGFont.

This is an alternate approach to aadbc6deca05.

CTFontCreateWithGraphicsFont seems to give "LastResort" when used on a
system CGFont with variation applied on 10.12-10.14. We can avoid that
by using CTFontCreateWithGraphicsFont with a variation descriptor.

I'm only applying this approach to cairo for now to mimimize the risk
of this breaking something or causing the crashes that we were seeing
before.

See https://github.com/servo/core-foundation-rs/pull/439 for
a standalone test case.

Pushed by jmuizelaar@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7d2a2cfde898
Fix creating variation CTFonts. r=lsalzman

Emil, could you please re-test this across the various macOS versions (like in comment 20) with the latest Nightly (Feb 10th)? If Jeff's new fix works reliably on all the versions, it's the better solution here.

Flags: needinfo?(emil.ghitta)

I have re-tested this issue on Firefox 87.0a1 (BuildId:20210210094937) using:

  • macOS 10.12
  • macOS 10.13
  • macOS 10.14
  • macOS 10.15
  • macOS 11.1

I can confirm that this issue is not reproducible. The https://voucher.gov.gr/ui/project/37/personal page is successfully displayed on both save to pdf and physical printers outputs.

Flags: needinfo?(emil.ghitta)

Comment on attachment 9202157 [details]
Bug 1690235. Fix creating variation CTFonts.

Beta/Release Uplift Approval Request

  • User impact if declined: Correctness (bug 1690730) and performance (bug 1691718)
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is lower risk alternative to the earlier patch that landed in beta.
  • String changes made/needed:
Attachment #9202157 - Flags: approval-mozilla-beta?

(In reply to Emil Ghitta, QA [:emilghitta] from comment #42)

I have re-tested this issue on Firefox 87.0a1 (BuildId:20210210094937) using:

  • macOS 10.12
  • macOS 10.13
  • macOS 10.14
  • macOS 10.15
  • macOS 11.1

I can confirm that this issue is not reproducible. The https://voucher.gov.gr/ui/project/37/personal page is successfully displayed on both save to pdf and physical printers outputs.

Thanks for confirming that; sounds good.

Could I ask for one more test as well, please? I'll attach a simple testcase that exercises the macOS system font variations; if you could confirm that it prints successfully across all macOS versions, that would be great. In particular, please check that the different weights of the font, and the different optical sizes, look the same in the PDF/printed output as they do within the browser.

(I expect the result may not look quite the same across the different macOS versions, because of changes to the system font; but in each case, the printed output should match how the screen display looks on the same version.)

Flags: needinfo?(emil.ghitta)

Comment on attachment 9202157 [details]
Bug 1690235. Fix creating variation CTFonts.

Approved for 86 beta 9, thanks.

Attachment #9202157 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Depends on: 1618687
No longer depends on: 1618687

(In reply to Pulsebot from comment #39)

Pushed by jmuizelaar@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7d2a2cfde898
Fix creating variation CTFonts. r=lsalzman

== Change summary for alert #28742 (as of Thu, 11 Feb 2021 10:40:48 GMT) ==

Improvements:

Ratio Suite Test Platform Options Absolute values (old vs new)
7% twinopen ext+twinopen:twinopen.html macosx1014-64-shippable-qr e10s stylo webrender-sw 114.98 -> 107.17
6% twinopen ext+twinopen:twinopen.html macosx1014-64-shippable-qr e10s stylo webrender 129.99 -> 122.43

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=28742

The output for the test case provided in comment 45 (for each macOS version) looks similar to the print preview.

Tested this using macOS versions: 10.12, 10.13, 10.14, 10.15 & 11.1

Here is a link to the google drive where you can find the save to pdf outputs for each macOS version.

Flags: needinfo?(emil.ghitta)

== Change summary for alert #28749 (as of Thu, 11 Feb 2021 13:19:08 GMT) ==

Improvements:

Ratio Suite Test Platform Options Absolute values (old vs new)
3% Heap Unclassified macosx1014-64-shippable-qr tp6 104,208,222.79 -> 100,704,284.06
2% Explicit Memory macosx1014-64-shippable-qr tp6 496,129,849.14 -> 484,222,568.94
2% Explicit Memory macosx1014-64-shippable-qr tp6 496,559,357.28 -> 485,855,418.38

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=28749

(In reply to Emil Ghitta, QA [:emilghitta] from comment #49)

The output for the test case provided in comment 45 (for each macOS version) looks similar to the print preview.

Tested this using macOS versions: 10.12, 10.13, 10.14, 10.15 & 11.1

Here is a link to the google drive where you can find the save to pdf outputs for each macOS version.

Thanks for the testing, Emil; looks like things are working OK here.

This is verified fixed on 86.0 using both macOS 10.14 and 10.13

Added a test case for this issue.

Status: RESOLVED → VERIFIED
status-firefox86: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: