Closed Bug 1306001 Opened 8 years ago Closed 8 years ago

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

Categories

(Web Compatibility :: Site Reports, defect)

Product:
Web Compatibility
Component:
Site Reports
Version:
Firefox 49
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

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

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
platform-rel --- +
firefox49 --- wontfix
firefox50 --- wontfix
firefox51 + fixed
firefox52 + fixed

People

(Reporter: krdell, Unassigned)

Details

(Keywords: regression, Whiteboard: [platform-rel-Microsoft][platform-rel-Outlook]) 

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
Could you test with a clean profile, pleae.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
Component: Untriaged → Printing: Output
Flags: needinfo?(krdell)
Product: Firefox → Core
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...
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
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
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...

  about:config?filter=layout.css.prefixes.webkit

...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.)
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.)
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.
(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.
Thanks for tracking this down, Laurent! Regression from bug 1271521 maybe?
Status: UNCONFIRMED → NEW
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
It could be another regression of bug 1190641 similar to bug 1306384.
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'
                  onclick='window.print()'>"
          sandbox="allow-scripts"></iframe>

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);'>"
          sandbox="allow-scripts"></iframe>

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.

Thanks
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 ?
Still not working for me :(
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!
Status: NEW → RESOLVED
Closed: 8 years 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.
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.