flypig.co.uk

It has to be said, I'm pretty frustrated with myself. I've looked over the code in printUtils.js over and over again and I just can't seem to figure out what I'm doing wrong. I've been poring over this code for days now.

In theory it might be possible to create a browser element and add it to the current page, and use that as the print source. This seems to be roughly what the print preview is doing in the code that emilio highlighted:

  startPrintWindow(aBrowsingContext, aOptions) {
[...]
    if (openWindowInfo) {
      let printPreview = new PrintPreview({
        sourceBrowsingContext: aBrowsingContext,
        openWindowInfo,
      });
      let browser = printPreview.createPreviewBrowser("source");
      document.documentElement.append(browser);
      // Legacy print dialog or silent printing, the content process will print
      // in this <browser>.
      return browser;
    }

    let settings = this.getPrintSettings();
    settings.printSelectionOnly = printSelectionOnly;
    this.printWindow(aBrowsingContext, settings);
    return null;
  },

That call to createPreviewBrowser() goes on to do something like this:

  createPreviewBrowser(sourceVersion) {
    let browser = document.createXULElement("browser");
[...]
      browser.openWindowInfo = this.openWindowInfo;
[...]
    return browser;
  }

So it looks like the code is creating a browser element, appending it to the document and then... well, then what? It doesn't call printWindow() on the result, it just returns it. That could be because it's opening the print preview and waiting for the user to hit the "Print" button, but if that's the case it's no good for what I need, because I want it to go ahead and print straight away.

To assuage my frustration I'm going to leave this and — even if there is a solution that avoids it — just go ahead and implement the page hiding functionality that I've been talking about for the last few days. It feels like a defeat though, because there should be some other way, I just can't quite put my finger on it. And that's because I can't properly follow the flow of the code when it's all so abstract.

Alright, it's time to cut my losses and move on.

At least finally this means I've been able to actually do some coding. I've added a hidden (in some cases isHidden to match the style of a particular interface) parameter to various window creation methods scattered around the EmbedLite code. Changes like this:

--- a/embedding/embedlite/PEmbedLiteApp.ipdl
+++ b/embedding/embedlite/PEmbedLiteApp.ipdl
@@ -18,12 +18,12 @@ nested(upto inside_cpow) sync protocol PEmbedLiteApp {
 parent:
   async Initialized();
   async ReadyToShutdown();
-  sync CreateWindow(uint32_t parentId, uintptr_t parentBrowsingContext, uint32_t chromeFlags)
+  sync CreateWindow(uint32_t parentId, uintptr_t parentBrowsingContext, uint32_t chromeFlags, bool hidden)
     returns (uint32_t createdID, bool cancel);
   async PrefsArrayInitialized(Pref[] prefs);

This has knock-on effects to a lot of files, but all of them follow similar lines: a parameter is added to the method signature which is then passed on to some other method that gets called inside the method definition. I'm not going to list all of the changes here, but just note that it cascades throughout the EmbedLite portion of the code, across 22 files in total:

$ git status
On branch sailfishos-esr91
Your branch is up-to-date with 'origin/sailfishos-esr91'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)
        modified:   embedding/embedlite/EmbedLiteApp.cpp
        modified:   embedding/embedlite/EmbedLiteApp.h
        modified:   embedding/embedlite/PEmbedLiteApp.ipdl
        modified:   embedding/embedlite/embedprocess/EmbedLiteAppProcessParent.cpp
        modified:   embedding/embedlite/embedprocess/EmbedLiteAppProcessParent.h
        modified:   embedding/embedlite/embedprocess/EmbedLiteViewProcessParent.cpp
        modified:   embedding/embedlite/embedprocess/EmbedLiteViewProcessParent.h
        modified:   embedding/embedlite/embedshared/EmbedLiteAppChild.cpp
        modified:   embedding/embedlite/embedshared/EmbedLiteAppChild.h
        modified:   embedding/embedlite/embedshared/EmbedLiteAppChildIface.h
        modified:   embedding/embedlite/embedshared/EmbedLiteAppParent.h
        modified:   embedding/embedlite/embedshared/EmbedLiteViewChild.cpp
        modified:   embedding/embedlite/embedshared/EmbedLiteViewChild.h
        modified:   embedding/embedlite/embedshared/EmbedLiteViewParent.cpp
        modified:   embedding/embedlite/embedshared/EmbedLiteViewParent.h
        modified:   embedding/embedlite/embedthread/EmbedLiteAppThreadParent.cpp
        modified:   embedding/embedlite/embedthread/EmbedLiteAppThreadParent.h
        modified:   embedding/embedlite/embedthread/EmbedLiteViewThreadChild.cpp
        modified:   embedding/embedlite/embedthread/EmbedLiteViewThreadChild.h
        modified:   embedding/embedlite/embedthread/EmbedLiteViewThreadParent.cpp
        modified:   embedding/embedlite/embedthread/EmbedLiteViewThreadParent.h
        modified:   embedding/embedlite/utils/WindowCreator.cpp
        modified:   gecko-dev (new commits, untracked content)

no changes added to commit (use "git add" and/or "git commit -a")

These changes will also have impacts elsewhere, in particular I expect them to bubble up into the qtmozembed and sailfish-browser code as well. In fact, I'm absolutely hoping they will be because because the entire point is to get the details about the need to hide the window into the sailfish-browser code where it can actually be made to do something useful.

However, having made these changes, a partial build doesn't work because the PEmbedLiteApp.ipdl code needs to be regenerated, so I'm going to have to set this going on a full build overnight. I've tested the changes as far as possible by running partial builds but it won't fully go through because of this. I'll just have to hope that I covered all of the changes needed.

While it builds I could start looking at the code in the other packages, but without the gecko headers to build against I won't be able to compile any of those other changes either, so I'm going to leave those until tomorrow as well.

Here's hoping the build goes through okay!

If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.