bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

New FF version 49.0.1 is unable to print calendars in OWA Office 365. Works in all other browsers



Tech Evangelism
2 years ago
a year ago


(Reporter: Kordell, Unassigned)



Firefox 49

Firefox Tracking Flags

(platform-rel +, firefox49 wontfix, firefox50 wontfix, firefox51+ fixed, firefox52+ fixed)


(Whiteboard: [platform-rel-Microsoft][platform-rel-Outlook])



2 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36

Steps to reproduce:

Open calendar in OWA Outlook 365 and try to print from Firefox.  

Actual results:

Clicking print brings on the print preview windows yields no results whatsoever

Expected results:

It should bring up the print dialog box which allows for selecting print options.  This functions fine in all other browsers and in previous firefox versions

Comment 1

2 years ago
Could you test with a clean profile, pleae.
Component: Untriaged → Printing: Output
Flags: needinfo?(krdell)
Product: Firefox → Core

Comment 2

2 years ago
I am afraid I get the same result with a clean profile
Maybe, this depends on web service.  (I met this issue 1 year ago on office 365 and outlook.com)

Firefox cannot print a page that is loading state.  outlook.com and office 365's calendar is always/often polling update to server, so Firefox keeps the page state that this page is loading.  So Firefox cannot print the page.  If page load is completed, Firefox can print the page.

So if you click stop icon on browser, it will be able to be resolved...

Comment 4

2 years ago
This does not work as the browser is not in a loading state and the option to stop loading is not available.  It only shows the refresh option (because the page is finished loading).  Again, this was not an issue previous to 49.0.1 and no other browsers have this issue

Comment 5

2 years ago
Exactly my problem. I contact O365 support who indicate me that this problem is a mozilla problem and they can not give me a solution.

When you click on the first print button on the calendar, you go to a page that give you some few choice setting (choice of the calendar, choice of the period ...). 
When you are ready to print you click on the second print button but it only reload the page instead of open the printer choice box.

I have no problem with FF 48.
The problem appeared with FF49.
I test with nightly 52.0a1 and the problem is exactly the same.
No problem with chrome, IE and edge.

The problem is that FF is our corporate browser, i would be bore to say to my users that now they must use IE.
I'll re open my case on microsoft support to indicate this bug number

Comment 6

2 years ago
As it looks like a regression in FF49, can you download the tool mozregression to narrow down a regression range.
See http://mozilla.github.io/mozregression/ for details to use it.
Run the command "mozregression --good=48" then copy here the final pushlog from the repository mozilla-inbound.
Flags: needinfo?(laurent.boisrobert)
Keywords: regressionwindow-wanted
Laurent or Koirdell: could you try visiting this special URL...


...and double-click the line for "layout.css.prefixes.webkit" that shows up there (so that it changes from "true" to "false"), and see if that makes the problem go away?

(That preference controls a new feature that we shipped in Firefox 49, and it could conceivably get us trouble with printing, depending on a site's CSS.)

Comment 8

2 years ago
I try it (in FF49.0.1 and nightly 52.0a1)  but that didn't change. The page reload but no printer box appears.
OK, thanks! It's good to rule out that pile of features. (you probably want to restore that layout.css.prefixes.webkit pref to its original setting)

In that case, Loic's mozregression suggestion is the best way forward here.  (That'll tell us precisely when/why this broke, hopefully.)

Comment 10

2 years ago
Sorry but my installation of mozregression don't work behind my authenticated proxy.
so i can't do the test that suggest Loic for the moment.

Comment 11

2 years ago
(In reply to Laurent Boisrobert from comment #10)
> Sorry but my installation of mozregression don't work behind my
> authenticated proxy.
> so i can't do the test that suggest Loic for the moment.

Follow https://bugzilla.mozilla.org/show_bug.cgi?id=999052#c1 to set an authenticating proxy in python requests.
Comment hidden (obsolete)
Thanks for tracking this down, Laurent! Regression from bug 1271521 maybe?
status-firefox49: --- → wontfix
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox52: --- → affected
Ever confirmed: true
Flags: needinfo?(laurent.boisrobert)
Flags: needinfo?(krdell)
Flags: needinfo?(bzbarsky)
Keywords: regressionwindow-wanted → regression

Comment 15

a year ago
It could be another regression of bug 1190641 similar to bug 1306384.


a year ago
Component: Printing: Output → DOM
> It could be another regression of bug 1190641 similar to bug 1306384.

It's possible.  If the page is using window.print() and sandboxing without allow-modals, that will be blocked after bug 1190641.  Simple testcase:

  <iframe srcdoc="<input type='button' value='click me to try to print'

Note that clicking the button does nothing, but adding "allow-modals" to the sandbox attribute makes it work.

That said, the behavior is the same in Chrome on that testcase.  So either that's not the issue or the site is sending different markup to different browsers.

I do have access to OWA, but apparently not Outlook 365, because printing the calendar in the OWA I have access to works for me in both nightly and in Firefox 49....

Laurent, are you willing to open the page that you click the second "print" button on in Firefox's and Chrome's devtools and see whether it contains any iframes with sandbox attributes, and if so what the values of those attributes are?  Also, are you willing to check what happens if you spoof the Chrome user-agent string in Firefox?
Flags: needinfo?(bzbarsky) → needinfo?(laurent.boisrobert)
I try your simple testcase. 
In an older Firefox (FF47) i have the printer box. 
In the last FF I don't have the printer box. 
You are right. With this page chrome don't give me the printer box.
With O365 chrome give me a page different than the Windows printer box and i can print.

If you want a test account i could give you on a O365 from my sport association.

I have to work to another problem this day so i can't test anymore for the moment.
> If you want a test account i could give you on a O365 from my sport association.

That would be incredibly helpful!  Thank you!
(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #18)
> > If you want a test account i could give you on a O365 from my sport association.
> That would be incredibly helpful!  Thank you!

I just send you an account. Excuse me for the delay.
Perfect, thanks.

So the upshot is that the site has an iframe sandboxed with sandbox="allow-same-origin allow-scripts".  And in the printElement() function in https://r1.res.office365.com/owa/prem/16.1449.13.2132672/scripts/printelement.js it writes a string into that iframe using document.write().  That string is built up out of various pieces, but one of those pieces is defined like so:

    s = $.browser.mozilla ? 'window.print();' : 'document.execCommand("print", false, null);';

I haven't found yet where $.browser.mozilla is set, and based on what, but it's certainly set to true in Firefox and not set in Chrome, so Firefox does window.print() while Chrome does the exectCommand() call.

A simple testcase shows that Chrome _will_ put up a print dialog for that execCommand call even when the document is sandboxed:

  <iframe srcdoc="<input type='button' value='click me to try to print'
                  onclick='document.execCommand(&quot;print&quot;, false, null);'>"

This seems like a bug in Chrome; I filed https://bugs.chromium.org/p/chromium/issues/detail?id=658985 on them.

As far as our options here, I think they are:

1)  Stop preventing window.print() when modals as disallowed in the sandbox.
    Get the HTML spec changed accordingly.
2)  Implement document.execCommand("print") as an alias for window.print() but
    without it obeying the sandbox flags (a la Chrome).  I see zero benefit to
    doing this over option #1, honestly.
3)  Get microsoft to add "allow-modals" to that iframe.

Laurent, are you willing to contact Microsoft support again and point out to them that this last is a simple solution on their end and that Firefox is following the spec here?  I'll try to contact Microsoft as well; we have some internal channels for that....
[Tracking Requested - why for this release]: Broken printing in OWA Office 365.

Oh, and option 2 _also_ requires us to get the site to not detect us as "mozilla", or course, whatever that entails.  Which makes it even less desirable.

I Microsoft doesn't respond quickly, we should just go ahead and do option 1 in Firefox 50+, until other browsers disable execCommand("print") when sandboxed without allow-modals.  That will presumably cause OWA Office 365 to notice that something is up, maybe.
tracking-firefox50: --- → ?
tracking-firefox51: --- → ?
tracking-firefox52: --- → ?
If you want i can open a new Microsoft ticket (or reopen my first ticket)

I already give Microsoft this bug id, but for them it is a Firefox problem. 
I could give them your great analyse of the problem.


Comment 23

a year ago
I missed this in Chrome's implementation, and (for better or worse) `execCommand` isn't exactly well-specified.

Laurent, if you have a contact at Microsoft, please point them to https://bugs.chromium.org/p/chromium/issues/detail?id=658985 (and https://codereview.chromium.org/2448833003), where I intend to match Firefox's behavior. Adding `allow-modals` to the sandbox attributes is the right solution, and it would be best if we could work with them together to advocate that change.
> If you want i can open a new Microsoft ticket (or reopen my first ticket)

That would be much appreciated, if you're willing to do that!
Ted Dinklocker - Microsoft
Adding support for 'allow-modals' and 'allow-popups-to-escape-sandbox' to Microsoft Edge are both on our backlog - unknown ETA at this time.
If you need contacts for O365, please reach out and I can help.
platform-rel: --- → +
Whiteboard: [platform-rel-Microsoft][platform-rel-Outlook]
Track 51+/52+ as broken printing in OWA Office 365.
tracking-firefox51: ? → +
tracking-firefox52: ? → +
Mark 50 won't fix and 51 fix-optional due to no ETA for adding support for 'allow-modals' and 'allow-popups-to-escape-sandbox'.
status-firefox50: affected → wontfix
status-firefox51: affected → fix-optional
tracking-firefox50: ? → ---
The Microsoft folks tell me they're working on a fix, for what it's worth.
(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #28)
> The Microsoft folks tell me they're working on a fix, for what it's worth.

Idem, my Microsoft support ticket is now close and the information is transmit to the dev team.
Good news, my calendar printing function is woking today.
Is it ok for the other ?

Comment 31

a year ago
Still not working for me :(

Comment 32

a year ago
I lied, it's working for me now on Windows and PC...thanks!
Sounds like they rolled out the fix.  Moving over to tech evangelism and resolving.

Thank you Kordell for filing this, and Laurent for the account so we could figure out what was going on here!
Last Resolved: a year ago
Component: DOM → Desktop
Flags: needinfo?(laurent.boisrobert)
Product: Core → Tech Evangelism
Resolution: --- → FIXED
Version: 49 Branch → Firefox 49
Thank you Boris, 
you've done all the diagnostic that Microsoft should have done when i open my support ticket.

And thanks for Microsoft for applying the patch.
One regret, no visibility on when Microsoft patching OWA in contrast of this bugzilla.
status-firefox51: fix-optional → fixed
status-firefox52: affected → fixed
You need to log in before you can comment on or make changes to this bug.