As mentioned in bug 890690 comment 14, the current implementation to support POST search engines in about:home duplicates behavior as implemented by nsSearchService.getSubmission(). To allow getSubmission() to be called from a non-chrome context like about:home, we need to use events to transfer messages between differently privileged areas.

Gavin, as you might notice from this patch, I can pretty much revert the entire changeset from bug 890690. Is there a reason you might still postDataString somewhere? If not, I'll revert all those changes to this new - preferred - way of doing things. Instead of introducing a new event, I simply reused 'AboutHomeSearchEvent', which was only used for FHR. I was careful not to break the FHR mechanism (and luckily, it is covered by a unit test). Do you agree that that is the correct direction? Thanks!

In fact, in this case we don't even need the 'searchEngineURL' attribute anymore for about:home... Since this is starting to look so elegant and simple, I begin to wonder if this implementation was tried before, but disregarded for some reason?

Comment on attachment 788904 [details] [diff] [review] Patch v1: make about:home call nsSearchService.getSubmission Looks good - this does look like it will simplify things a lot. The history is in bug 563723. IIRC we didn't take this approach just because it wasn't necessary (about:home then was less tied to the search service and had a hardcoded list of engines, didn't support POST data, etc.).

Part of this patch is about reverting the code I added for bug 890690. I also reverted the UUID of nsISearchEngine, is that the correct thing to do? I also removed the searchEngineURL attribute and the corresponding code in AboutHomeUtils.jsm. \o/ I checked the unit tests and they run without problems. Could do a try run to be safe.

Report exception when it occurs. This will never ever happen, but still...

Try run looks good.

Comment on attachment 789201 [details] [diff] [review] Patch v1.3: make about:home call nsISearchEngine.getSubmission >diff --git a/browser/base/content/abouthome/aboutHome.js b/browser/base/content/abouthome/aboutHome.js > function onSearchSubmit(aEvent) >+ // Send an event that will perform a search. This was originally added so >+ // Firefox Health Report could record that a search from about:home had >+ // occurred, but now it will also perform the search (properly) in >+ // browser.js through nsISearchEngine.getSubmission(). I think the "this was originally added" bit is not really relevant to someone looking at this code (and can be found in blame), so I would just remove it. >diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js > let updateSearchEngine = function() { >+ // Again, keep the searchEngineName as the last attribute, because the > // mutation observer in aboutHome.js is counting on that. >+ docElt.setAttribute("searchEngineName", Services.search.defaultEngine.name); This comment isn't so useful now, since it's not the only attribute. >+ // Trigger a search through nsISearchEngine.getSubmission() >+ let submission = Services.search.currentEngine.getSubmission(data.searchTerms); >+ openUILinkIn(submission.uri.spec, "current", null, submission.postData); I think this might do the wrong thing if about:home is loaded in an app tab (it will open the search in a new tab). Probably better to use gBrowser.loadURI? Also, in theory you want to use the same tab that the event bubbles up from, rather than the currently selected tab, but since I think it's impossible for the event to be fired in a background tab in practice, I guess you don't need to worry about that. r=me with those addressed.

and sorry for the delay!

Patch with Gavin's comments addressed. Carrying over r=gavin.

Backed out for mochitest-bc crashes. https://hg.mozilla.org/integration/fx-team/rev/e994f93c5b39

Log: https://tbpl.mozilla.org/php/getParsedLog.php?id=27132398&tree=Fx-Team

Another try push for this, because I only see Win XP crashes in the logs... https://tbpl.mozilla.org/?tree=Try&rev=d2aeead9167a

Try push looks good, so I attempted another push to integration: https://hg.mozilla.org/integration/fx-team/rev/41729438f597

Still crashing, even after a clobber. https://hg.mozilla.org/integration/fx-team/rev/a93b157d7ab4

Now with a completely new UUID for the nsISearchSubmission interface.

Trying _again_ with this new version. https://hg.mozilla.org/integration/fx-team/rev/75d9df61d0e1