1733756 - Build error "no member named 'History' in namespace 'mozilla::components'" with new Mozilla application

Status: NEW

(Core :: XPCOM, task)

Description

[Alex Vincent [:WeirdAl]]

In attempting a compile of a new Mozilla application, I was running into these weird errors:

In file included from Unified_cpp_docshell_base0.cpp:101:
/home/ajvincent/debugging/bapp-coroner/mozilla-central/docshell/base/nsDocShell.cpp:12073:32: error: no member named 'History' in namespace 'mozilla::components'; did you mean 'IHistory'?
  nsCOMPtr<IHistory> history = components::History::Service();
                               ^~~~~~~~~~~~~~~~~~~
                               IHistory
/home/ajvincent/debugging/bapp-coroner/newapp-sym/dist/include/mozilla/Services.h:459:7: note: 'IHistory' declared here
class IHistory;

There were five source files impacted, as the upcoming patch will show. Four of them in dom, three in dom/ipc.

Replacing these with services::GetHistory() and recompiling Firefox worked beautifully. mach test dom/ipc shows tests passing, and manually stepping through in ddd with one of the files shows we still get a consistent history service.

Reproducing the build bustage will require following the steps at the URL field. I still have a build bustage after this patch, but it's well downstream of these files. That build bustage is to be expected in an experimental, work-in-progress project like this, which doesn't touch the rest of the Mozilla tree.

Comment 1

[Alex Vincent [:WeirdAl]]

Attachment: Bug 1733756 - Replace references to components::History::Service with services::GetHistory. r=mccr8

Comment 2

[Andrew McCreight [:mccr8]]

Like I said in the bug review, this is basically reverting an existing patch, so I don't think this is going to be the right fix.

https://hg.mozilla.org/mozilla-central/rev/f6a2f878fa0f8f7df6121c936621b1744fa1c692

I'm not sure why you are seeing this error. It kind of looks like a unified build error, where something isn't including the correct header, but docshell/base/ builds just fine in non-unified mode when I tried it. If you added new files, you could try putting them in SOURCES instead of UNIFIED_SOURCES and see if that makes it clearer what is going wrong.

Comment 3

[Andrew McCreight [:mccr8]]

Another possibility is that the script to generate the services header got messed up somehow, or isn't running when it should be. It looks like that History::Service method is supposed to be in objdir/xpcom/components/Components.h

Comment 4

[Andrew McCreight [:mccr8]]

I'm going to change this bug to be about fixing the build error, as that's presumably what you are really after here.

Comment 5

[Alex Vincent [:WeirdAl]]

helpwanted: I thought I had an easy solution to this build error, but I was wrong, and the particular kind of failure :mccr8 describes is not one I'm equipped to handle.

If you added new files, you could try putting them in SOURCES instead of UNIFIED_SOURCES and see if that makes it clearer what is going wrong.

I did, but none of them are C++ or Rust files. There was no SOURCES or UNIFIED_SOURCES in my newapp project. So that's not it.

Another possibility is that the script to generate the services header got messed up somehow, or isn't running when it should be. It looks like that History::Service method is supposed to be in objdir/xpcom/components/Components.h

I suspect this to be the case. When I looked at the generated Components.h after my build failure, History::Service wasn't there.

Comment 6

[Alex Vincent [:WeirdAl]]

OK, I figured out why my build was breaking and browser, mail, suite weren't.

In my project's moz.configure file, the simple fix is this:

# this is required to define mozilla::components::History::GetServiceHelper in objdir/xpcom/components/Components.h
imply_option("MOZ_PLACES", True)

This seems like the wrong solution, though. Bug 1686616 introduced the dependency on History::GetServiceHelper, and the target project shouldn't matter. I think this should no longer be a configuration setting, but the default value for all operations.

Comment 7

[Alex Vincent [:WeirdAl]]

OTOH, I am not familiar with the toolkit/components/places code, so I don't exactly know what it does.

Comment 8

[Alex Vincent [:WeirdAl]]

OK, I just have no idea what the Right Fix is.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 10

[Suhaib Mujahid [:suhaib]]

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.