1199229 - input type number not printing value when @font-face is used

Status: VERIFIED DUPLICATE of bug 1229212

(Core :: Printing: Output, defect)

Description

[daniel.koetting]

Attachment: numberFontFace.txt

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150812163655

Steps to reproduce:

Created an html document containing an input with type number and a font loaded via googlefontsapis.com. 


Actual results:

In print preview and actual printout the value of the input is not shown / printed.
The attached textfile contains two very simple html testcases with and without @font-face.


Expected results:

The value should be shown in the preview and printed out.

Comment 1

[Arnd]

Confirmed. Even worse: Any text directly after the input type number field is not printed either.

Comment 2

[Abe - QA (:Abe_LV)]

 User Agent:	Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0
 Nightly 45.0a1 Build ID:  20151204030208
 and Firefox 42.0


I am unable to reproduce it. The page itself, print preview and the actual print are the same.
Are you still able to reproduce this in the latest version ?

Comment 3

[daniel.koetting]

I am still able to reprocude with the attached testcase and the latest version.

Weird thing is, that the first testprint with @font-face had the number on it.
After this print i opened printpreview and the number field was gone.
The next print did not show the field anymore and even restarting firefox does not bring it back on the printed copy.

Comment 4

[Abe - QA (:Abe_LV)]

Attachment: actual page and script.PNG

Comment 5

[Abe - QA (:Abe_LV)]

Attachment: print preview.PNG

Hi Daniel,

I attached screen copy the actual page and the print preview. 
The page values do not change after print or print preview. The values can be changed and it does not change by printing the page. I play with this in different scenarios. It is working for me. Have you tried it in fresh install ?

Comment 6

[Abe - QA (:Abe_LV)]

Same message as above, only I selected"reporter" in this case.
-------------------------------------------------------------
Hi Daniel,

I attached screen copy the actual page and the print preview. 
The page values do not change after print or print preview. The values can be changed and it does not change by printing the page. I play with this in different scenarios. It is working for me. Have you tried it in fresh install ?

Comment 7

[Abe - QA (:Abe_LV)]

My test environment:

User Agent 	Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Version 	46.0a1
Build ID 	20160113030207
Channel 	nightly

Comment 8

[Abe - QA (:Abe_LV)]

and 
User Agent 	Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Version 	46.0a1
Build ID 	20160113030207
Channel 	nightly 
and Firefox 43.0

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: reporter's testcase

Here's the supposedly-broken HTML from the original attachment. I don't have any problems print-previewing it -- the number contents show up.

(The number also still shows up if I explicitly style the input with the included web font, too. The testcase doesn't do that, but I wonder if it was meant to?  Anyway, worksforme with that change as well.)

Comment 10

[daniel]

Attachment: index.html

This is a demonstration of the same bug I'm facing. In this case, the problem was triggered by using Font-Awesome icons.

How to reproduce: Just display the HTML code in the Browser. On the normal view, the number will appear in the input box. When you try to print the output, the number as well as the input box will disappear.

Comment 11

[Daniel Holbert [:dholbert]]

Still can't reproduce.

I see the icon, as well as the numbers inside the <input> field, in all of the following scenarios:
 - viewing the file directly
 - print-preview (File | Print Preview)
 - print to PDF (File | Print, "print to file", choose PDF)
 - print to PS (File | Print, "print to file", choose PS)

Comment 12

[Daniel Holbert [:dholbert]]

I tried the scenarios mentioned in Comment 11, using Nightly (46) as well as Release (43), on Linux. In Nightly, I tested with e10s enabled (the new default) as well as disabled.  Couldn't reproduce any missing numbers.

(caveat: I didn't test print-to-PS in all those configurations; that I only tested in nightly with e10s disabled.)

Comment 13

[daniel]

Attachment: Image.jpg

Example with version 43.04. I will try in other operating systems.

Comment 14

[Daniel Holbert [:dholbert]]

I just tried on Windows 10 with Firefox Nightly (46) and I'm still unable to reproduce there, for what it's worth.

A few questions:
 * Have you tried with a new Firefox profile? (This might be dependent on something special in your profile -- some addon or preference.)  More information on creating a new profile here:  https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles  Or you can just install Firefox Developer Edition (which manages its own profile), and refuse any offers that it makes to import pieces of your existing profile.

 * Can you reproduce the bug with the actual bugzilla-hosted version of your testcase? ( https://bugzilla.mozilla.org/attachment.cgi?id=8709724 )
(Asking because I noticed your "Image.jpg" is for a file:/// URL, i.e. you're viewing a local file on your machine -- and sometimes things work differently between web-hosted vs. locally-hosted files.  If you could confirm that the Bugzilla-hosted testcase definitely reproduces the problem for you, then that would rule out one possible explanation for why you can reproduce & others can't.)

Comment 15

[Daniel Holbert [:dholbert]]

Aha! Never mind about comment 14. I just tried Firefox release (version 43.04) and I can confirm that I do hit the bug, when viewing attachment 8709724 [details] in Print Preview, on Linux & Windows 10.

So, given that it reproduces in release but not in Nightly, this must've been fixed already, and the fix is just on its way to release.

Comment 16

[Daniel Holbert [:dholbert]]

The "mozregression" tool tells me this became fixed by this changeset:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4ec205ad08157abb71b492a10e423de4e971770e&tochange=f647c855f10b4c8e9e4d5b43c5bb1a4a05d38e50

Resolving as FIXED by bug 1229212 (in Firefox 45).  Daniel, if you'd be up for testing Firefox Developer Edition (whose current version should have the fix) to confirm that it's fixed there for you, that would be much appreciated -- thanks!

Comment 17

[daniel.koetting]

I just tested with Firefox Developer Edition and it seems to me that the bug is indeed fixed.
Previev, PDF and print on paper all show the number as expected.

Thank you very much for your help on this.

Comment 18

[Daniel Holbert [:dholbert]]

Great, thank you for verifying & thanks for filing the bug!

Comment 19

[Daniel Holbert [:dholbert]]

(I'm going to mark this as a duplicate of bug 1229212, actually, since that's a bit simpler from a tracking perspective.)