Closed Bug 1362817 Opened 3 years ago Closed 2 years ago

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.

Categories

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

53 Branch
x86
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla57
Tracking Status
firefox-esr52 --- unaffected
firefox53 --- wontfix
firefox54 --- wontfix
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- fixed

People

(Reporter: leftydoptera, Assigned: mantaroh)

References

Details

(Keywords: regression)

Attachments

(3 files)

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
Component: Untriaged → Printing: Output
Keywords: regression
OS: Unspecified → Linux
Product: Firefox → Core
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(olucafont6)
Too late to fix for 53 but we could still take a patch for 55/54.
(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?
Flags: needinfo?(xidorn+moz)
Flags: needinfo?(fatseng)
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.
Flags: needinfo?(xidorn+moz)
(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.
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.
Flags: needinfo?(olucafont6)
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.
emk, as you reviewed the patch of bug 1301640, could you have a look at this issue?
Flags: needinfo?(VYV03354)
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?
Flags: needinfo?(VYV03354) → needinfo?(cosmin.muntean)
I can't reproduce it on Ubuntu 14.04 with Beta53 and 54.
Flags: needinfo?(fatseng)
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.
Flags: needinfo?(cosmin.muntean)
Hardware: Unspecified → x86
emk, can you help to follow up this issue? Thanks.
Blocks: 1301640
Flags: needinfo?(VYV03354)
(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.)
Flags: needinfo?(VYV03354)
(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?
Flags: needinfo?(VYV03354)
(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 :(
Flags: needinfo?(VYV03354)
Duplicate of this bug: 1371994
Duplicate of this bug: 1373009
Any updates on this one?
root cause is bug 1400463 comment #1.  I think that this is on 32bit system only.
Assignee: nobody → 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
Duplicate of this bug: 1400463
(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.
Status: NEW → ASSIGNED
Priority: -- → P3
Comment on attachment 8909698 [details]
Bug 1362817 - Use PRTime instead of time_t in nsSimplePageSequenceFrame::Reflow.

https://reviewboard.mozilla.org/r/181214/#review186536
Attachment #8909698 - Flags: review?(m_kato) → review+
Comment on attachment 8909699 [details]
Bug 1362817 - Drop the DateTimeFormat::FormatTime().

https://reviewboard.mozilla.org/r/181216/#review186540
Attachment #8909699 - Flags: review?(m_kato) → review+
Why do we have no FormatTime gtest... :-<  There is no reason to keep FormatTime since FormatTime consumer is only this code.
(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.
Pushed by mantaroh@gmail.com:
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
https://hg.mozilla.org/mozilla-central/rev/16deccf18876
https://hg.mozilla.org/mozilla-central/rev/ddad6d9b200e
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
You need to log in before you can comment on or make changes to this bug.