1362817 - Printing from FireFox 53.0 32-bit on Linux Mint 17 qiana xfce 32-bit the datetime on the page prints as 12/31/69. This is new as of my last update.

Status: RESOLVED FIXED

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

Description

[Lefty Dopter]

Attachment: Firefox 53 DateTime 1969 Bug.pdf

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170421115307

Steps to reproduce:

Go to any web page (even about:blank)
File, Print



Actual results:

Date/Time prints as 12/31/69.  Time seems to start around 6:58 or so PM
Time increments
This happens with Print Preview, Print to PDF, etc.
Please refer to the lower right of the attached PDF



Expected results:

Current date and time should appear

Comment 1

[Cosmin Muntean [:cmuntean], Ecosystem QA]

User Agent  Mozilla/5.0 (X11; Linux i686; rv:53.0) Gecko/20100101 Firefox/53.0
Firefox: 53.0.2, Build ID: 20170504175505

I have managed to reproduce this issue on latest Firefox (53.0.2) release on Ubuntu 12.04 x32. Now date time on the printed pages, is wrongly displayed as: "1/1/70".  
Considering the fact that the issue is not reproducible on Firefox 52.0.2, I have performed a regression rage using the mozregression tools. Here are the results:

Last good revision: 44319b48939468ccee22cc03a4cae5e506c2847d
First bad revision: 7df260e7976967592f410331679250601e8b8fac
Pushlog: https://goo.gl/701g6G

Looking over the bugs from the generated pushlog, I suspect bug 1329076, that has the changes which introduced the regression.

Gregory, can you please take a look at this?

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late to fix for 53 but we could still take a patch for 55/54.

Comment 3

[Astley Chen (inactive)]

(In reply to Cosmin Muntean [:CosminMCG], Desktop Engineering QA from comment #1)
> Looking over the bugs from the generated pushlog, I suspect bug 1329076,
> that has the changes which introduced the regression.

I really don't think the fix for bug 1329076 could cause the regression like this.
I'm also unable to reproduce the symptom on ubuntu 16.04 with Nightly55 and Beta54 as well.

Farmer, could you help to verify whether you can reproduce in your environment or not?
Xidorn, any comments?

Comment 4

[Xidorn Quan [:xidorn] UTC+11]

I would suspect bug 1301640 in that range, which is datetime-related.

It seems the author of that patch (:gmoore) has been ni?ed in this bug.

Comment 5

[Cosmin Muntean [:cmuntean], Ecosystem QA]

(In reply to Astley Chen [:astley] (UTC+8) from comment #3)
> I really don't think the fix for bug 1329076 could cause the regression like
> this.
> I'm also unable to reproduce the symptom on ubuntu 16.04 with Nightly55 and
> Beta54 as well.

Sorry, my mistake. I typed the wrong number. I also suspect bug 1301640, that's why I ni?ed Gregory.
I think the issue is only reproducible on Linux x32 bits versions. I haven't managed to reproduce it on Ubuntu 16.04 x64.

Comment 6

[Gregory Moore [:gmoore]]

Hey everyone, sorry for replying so late. I recently started a new job, and I haven't really been working on Mozilla stuff since then. Otherwise I'd probably be interested, but I'd rather not work on this bug right now. Sorry about that, and thanks for asking.

Comment 7

[Xidorn Quan [:xidorn] UTC+11]

12/31/69 and 1/1/70 actually sounds like we are passing zero as UNIX timestamp somewhere, and the result differs because of timezone. I am confused by the time not being a round hour, though.

Comment 8

[Xidorn Quan [:xidorn] UTC+11]

emk, as you reviewed the patch of bug 1301640, could you have a look at this issue?

Comment 9

[Masatoshi Kimura [:emk]]

Looks like bug 1331466 that did not uplift on 53.

Cosmin, did you really confirm this bug with Beta 54/Nightly 55 on Linux x86_32?

Comment 10

[Farmer Tseng[:fatseng](inactive)]

I can't reproduce it on Ubuntu 14.04 with Beta53 and 54.

Comment 11

[Cosmin Muntean [:cmuntean], Ecosystem QA]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:54.0) Gecko/20100101 Firefox/54.0
Firefox: 54.0b9, Build ID: 20170518175637

(In reply to Masatoshi Kimura [:emk] from comment #9)
> Looks like bug 1331466 that did not uplift on 53.
> 
> Cosmin, did you really confirm this bug with Beta 54/Nightly 55 on Linux
> x86_32?

I have retested this issue on Ubuntu 14.04 x32 and I have managed to reproduce this issue on latest Firefox (53.0.3) release, latest Beta (54.0b9) build and also on latest Nightly (55.0a1, 2017-05-21) build.
Here is a screenshot with the issue: https://goo.gl/Ne8V96.

I have also tested on Ubuntu 14.04 x64 and the issue is no reproducible. From what I see the issue is only reproducible on Linux x32 bits (Linux i686).

@Masatoshi I don't think that the bug 1331466 has the same root cause like this issue, because I haven't managed to reproduce it on latest Nightly (55.0a1) build.
Please let me know if you need more information.

Comment 12

[Astley Chen (inactive)]

emk, can you help to follow up this issue? Thanks.

Comment 13

[Masatoshi Kimura [:emk]]

(In reply to Cosmin Muntean [:CosminMCG], Desktop Engineering QA from comment #11)
> @Masatoshi I don't think that the bug 1331466 has the same root cause like
> this issue, because I haven't managed to reproduce it on latest Nightly
> (55.0a1) build.
> Please let me know if you need more information.

Sorry, I don't follow. Bug 1331466 is fixed with Firefox 54 or later (including 55.0a1).
Is Intl API enabled on 32-bit builds? (See if "Intl" is present on the global object using ScratchPad or Web Console.)

Comment 14

[Cosmin Muntean [:cmuntean], Ecosystem QA]

(In reply to Masatoshi Kimura [:emk] from comment #13)
> Is Intl API enabled on 32-bit builds? (See if "Intl" is present on the global object using ScratchPad or Web Console.)

I am not sure if I am doing this right, but I have pasted the following code in Scratchpad: 
"if (window.Intl && typeof window.Intl === "object"){
    console.log("We are all good to go!");
}"

After I have clicked the "Run" button, the "We are all good to go!" message was displayed in Web Console. So, the Intl API is enabled on 32 bit builds or this method doesn't work?

>Sorry, I don't follow. Bug 1331466 is fixed with Firefox 54 or later (including 55.0a1).
I am also confused, are you saying that the fix for bug 1331466 should also fix this issue?

Comment 15

[Masatoshi Kimura [:emk]]

(In reply to Cosmin Muntean [:CosminMCG], Desktop Engineering QA from comment #14)
> >Sorry, I don't follow. Bug 1331466 is fixed with Firefox 54 or later (including 55.0a1).
> I am also confused, are you saying that the fix for bug 1331466 should also
> fix this issue?

At first I thought so, but you said Nightly 55.0a1 on Linux 32-bit had this problem. Now I have no idea why this breaks only with Linux 32-bit :(

Comment 18

[Lars]

Any updates on this one?

Comment 19

[Makoto Kato [:m_kato]]

root cause is bug 1400463 comment #1.  I think that this is on 32bit system only.

Comment 20

[Mantaroh Yoshinaga[:mantaroh]]

Thanks, Kato-san

(In reply to Makoto Kato [:m_kato] from comment #19)
> root cause is bug 1400463 comment #1.  I think that this is on 32bit system
> only.

We should use PR_Now() and DateTimeFormat::FormatPRTime() in nsSimplePageSequenceFrame::Reflow() :
http://searchfox.org/mozilla-central/rev/1c13d5cf85f904afb8976c02a80daa252b893fca/layout/generic/nsSimplePageSequenceFrame.cpp#314-316

Comment 22

[Astley Chen (inactive)]

(In reply to Makoto Kato [:m_kato] from comment #19)
> root cause is bug 1400463 comment #1.  I think that this is on 32bit system
> only.

Yes, it is. Thanks for working on this bug.

Comment 23

[Mantaroh Yoshinaga[:mantaroh]]

Attachment: Bug 1362817 - Use PRTime instead of time_t in nsSimplePageSequenceFrame::Reflow.

The nsSimplePageSequenceFrame::Reflow calls DateTimeFormat::FormatTime().
In 32 bit environment, this conversion will overflow. So this patch will use
DateTimeFormat::FormatPRTime() instead of it.

Review commit: https://reviewboard.mozilla.org/r/181214/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/181214/

Comment 24

[Mantaroh Yoshinaga[:mantaroh]]

Attachment: Bug 1362817 - Drop the DateTimeFormat::FormatTime().

Review commit: https://reviewboard.mozilla.org/r/181216/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/181216/

Comment 25

[Makoto Kato [:m_kato]]

Comment on attachment 8909698 [details]
Bug 1362817 - Use PRTime instead of time_t in nsSimplePageSequenceFrame::Reflow.

https://reviewboard.mozilla.org/r/181214/#review186536

Comment 26

[Makoto Kato [:m_kato]]

Comment on attachment 8909699 [details]
Bug 1362817 - Drop the DateTimeFormat::FormatTime().

https://reviewboard.mozilla.org/r/181216/#review186540

Comment 27

[Makoto Kato [:m_kato]]

Why do we have no FormatTime gtest... :-<  There is no reason to keep FormatTime since FormatTime consumer is only this code.

Comment 28

[Mantaroh Yoshinaga[:mantaroh]]

(In reply to Makoto Kato [:m_kato] from comment #27)
> Why do we have no FormatTime gtest... :-<  There is no reason to keep
> FormatTime since FormatTime consumer is only this code.

Thank you for your review, Kato-san.

Comment 29

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/16deccf18876
Use PRTime instead of time_t in nsSimplePageSequenceFrame::Reflow. r=m_kato
https://hg.mozilla.org/integration/autoland/rev/ddad6d9b200e
Drop the DateTimeFormat::FormatTime(). r=m_kato

Comment 30

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/16deccf18876
https://hg.mozilla.org/mozilla-central/rev/ddad6d9b200e