Enable window.print() for Linux

[mrunalk]

This enables window.print() api so that crosswalk based apps can print within their app.
It doesn't provide Print Preview like Chrome but does pop up system print dialog to
configure print settings. It also relies on a small modification to build/common.gypi
in chromium-crosswalk repo to disable the print preview for which I will submit a
seprate PR.

BUG=XWALK-5680

[crosswalk-trybot]

Testing patch series with mrunalk/crosswalk@5abc149 as its head.

Bot	Status
Crosswalk Android-X86	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Crosswalk Android-X86/builds/4692)
Crosswalk Android x86-64	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Crosswalk Android x86-64/builds/1740)
Crosswalk Linux	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Crosswalk Linux/builds/4682)

[crosswalk-trybot]

Testing patch series with mrunalk/crosswalk@36ffa22 as its head.

Bot	Status
Crosswalk Android-X86	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Crosswalk Android-X86/builds/4693)
Crosswalk Android x86-64	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Crosswalk Android x86-64/builds/1741)
Crosswalk Linux	[FAILED 💔](https://build.crosswalk-project.org/try/builders/Crosswalk Linux/builds/4683)

[crosswalk-trybot]

Testing patch series with mrunalk/crosswalk@d45a698 as its head.

Bot	Status
Crosswalk Android-X86	[SUCCESS 💚](https://build.crosswalk-project.org/try/builders/Crosswalk Android-X86/builds/4694)
Crosswalk Linux	[SUCCESS 💚](https://build.crosswalk-project.org/try/builders/Crosswalk Linux/builds/4684)
Crosswalk Android x86-64	[SUCCESS 💚](https://build.crosswalk-project.org/try/builders/Crosswalk Android x86-64/builds/1742)

[crosswalk-trybot]

Testing patch series with mrunalk/crosswalk@e8bc8e3 as its head.

Bot	Status
Crosswalk Android-X86	[SUCCESS 💚](https://build.crosswalk-project.org/try/builders/Crosswalk Android-X86/builds/4702)
Crosswalk Android x86-64	[SUCCESS 💚](https://build.crosswalk-project.org/try/builders/Crosswalk Android x86-64/builds/1750)
Crosswalk Linux	[SUCCESS 💚](https://build.crosswalk-project.org/try/builders/Crosswalk Linux/builds/4692)

[mrunalk]

@darktears PTAL.

[crosswalk-trybot]

Testing patch series with mrunalk/crosswalk@3c27e36 as its head.

Bot	Status
Crosswalk Android-X86	[SUCCESS 💚](https://build.crosswalk-project.org/try/builders/Crosswalk Android-X86/builds/4703)
Crosswalk Android x86-64	[SUCCESS 💚](https://build.crosswalk-project.org/try/builders/Crosswalk Android x86-64/builds/1751)
Crosswalk Linux	[SUCCESS 💚](https://build.crosswalk-project.org/try/builders/Crosswalk Linux/builds/4693)

[darktears]

I'm not sure removing the Win specific part is a good idea right now. You're going to break potential users (not sure if we have any but still). If the code was landed in the first place it's because it was a request.

[mrunalk]

@darktears that's just a small piece of what Windows needs which I have removed here so that it will be easier on reviews. I'm working on Windows implementation in parallel which needs additional code. I'm also aware that making it work on Windows is the ultimate goal here.

[darktears]

as soon as you're confident that there will not be breakage (aka you land all the pieces before it reaches stable) then that's ok.

Other question : it seems that a bunch of code is copied from somewhere else, where is the origin?

[mrunalk]

Yes I should be able to land the Windows implementation before crosswalk 23 branches into beta. Lot of it is copied from Chromium's browser layer. All of the classes in runtime/browser/printing are copied from Chromium's chrome/browser/printing and adapted for Crosswalk. XWalkPrintWebViewHelperDelegate has been adapted from AwPrintWebViewHelperDelegate. Rest of the code in Crosswalk follows the flow and structure in Chromium. May be I should mention this as part of commit message.

[mrunalk]

@darktears ping

[darktears]

I wish we could avoid copying all of that...long term it's going to be a nightmare to make sure we back port fixes. Out of curiosity how hard was it to extract it from chrome/? Many classes seemed like a plain copy paste. Maybe it could go into components/printing?

[mrunalk]

I agree, I wish we could avoid copying the files in runtime/browser/printing too but since most of it is implemented in chrome I had to extract the minimum functionality from there to crosswalk. There is no point in reinventing the wheel here. May be some of it could be moved to components/printing but I don't see much progress upstream on any of the issues, 465802, 172158. Extracting the classes in runtime/browser/printing wasn't that difficult but there was quite a bit of work involved in adapting it in crosswalk code and making sure we are initializing and freeing up resources properly in line with chromium flow. I feel componentizing printing will require lot of effort because 1. it depends on system api's 2. There is lot of code for preview which requires UI 3. Cloud print is big component of it. Regarding backporting fixes it may seem lot of code to rebase but I don't think printing code changes that much.

[darktears]

Answering few of your comments :
-"much progress on 465802" -> maybe we can do it instead.
-" quite a bit of work in adapting the crosswalk code" -> Invariant here because componentized or not that's the same work for that particular piece.
Regarding the component effort :

1. I fail to see how this is an issue. Components are allowed to use system APIs.
2. Your part seems self contained. UI can still sit in chrome/ as a first step, you can can clearly justify to upstream that already making the proposed classes here inside components/ is helping downstream to provide basic printing functionalities.
3. Why just bringing the minimum as a first step? Cloud Print seems to me a clear second step.
   Regarding back porting, I was not talking about actually rebasing the code which most likely will be adapting the code there and there (though sometimes it turns out to be more significant than one think). I'm mostly talking about fixes that are landed in that class that will never get into what you're landing unless someone manually backport them -> this is not done automatically for you with rebase. git log show that you have several commits a month in the directory.

[mrunalk]

-"much progress on 465802" -> maybe we can do it instead.

Maybe...but that is outside the scope of this PR for now as it will take some time to implement it upstream. I am not sure if I can commit to it now. Current goal is to enable printing for our users with what we have in crosswalk and chromium.

Regarding the component effort :

1. I fail to see how this is an issue. Components are allowed to use system APIs.

Ok, may be that's possible then.

1. Your part seems self contained. UI can still sit in chrome/ as a first step, you can can clearly justify to upstream that already making the proposed classes here inside components/ is helping downstream to provide basic printing functionalities.
2. Why just bringing the minimum as a first step? Cloud Print seems to me a clear second step.

I don't quite understand what you mean here. If you are suggesting to componentize the printing functionality except cloud print first and then cloud print next, I agree with you.

Regarding back porting, I was not talking about actually rebasing the code which most likely will be adapting the code there and there (though sometimes it turns out to be more significant than one think). I'm mostly talking about fixes that are landed in that class that will never get into what you're landing unless someone manually backport them -> this is not done automatically for you with rebase. git log show that you have several commits a month in the directory.

Yes, it's possible we may miss some of the fixes done upstream. I don't think anyone can guarantee that with every rebase unless we componentize printing completely. As long as we have printing functionality working correctly for our users that is fine IMO.

[darktears]

• Who are the users requesting it? You're enabling Linux so far. Beside people over a Deepin there is not much going on. What's the pressure here?
• You are right, if the part you extracted was almost a copy paste of the files and provide a self contained functionality (which I believe it does) then that part itself upstream shouldn't be a problem. We can back port the patch in cr-crosswalk until it reaches it.
• Sure it's fine, not ideal. I'm trying to balance here if we desperately need this right now at the expense of few weeks (days even maybe) of work upstream so we can do the right thing.

I don't have strong opinion, it's just that we need to be careful on what we land and the cost is has considering the discussions ongoing.

[mrunalk]

Who are the users requesting it? You're enabling Linux so far. Beside people over a Deepin there is not much going on. What's the pressure here?

I think that question can be answered by @baleboy well. I am just responding to the needs conveyed to me by enabling the functionality. There were some customers who needed the print functionality on Android at one point(I don't want to name them here). But with our changing priorities I shifted the focus to Windows by starting with Linux implementation. After Windows I can also provide the implementation for Android. There is no pressure here as such but I want this basic implementation to pass the review or atleast get a positive signal so that I can move ahead on the Windows implementation. Otherwise it will just be a waste of time.

You are right, if the part you extracted was almost a copy paste of the files and provide a self contained functionality (which I believe it does) then that part itself upstream shouldn't be a problem. We can back port the patch in cr-crosswalk until it reaches it.

Once again, I don't plan to work on componentizing it as of now.

Sure it's fine, not ideal. I'm trying to balance here if we desperately need this right now at the expense of few weeks (days even maybe) of work upstream so we can do the right thing.

From my experience working on refactoring Speech API upstream it can also take months to pass reviews and land all the patches upstream. Again, I don't plan to work on upstreaming it as of now.