Should be possible.
Why should i do that?
BBLog always require the background page, immediately on start until the end, everytime the DOM changes in battlelog (almost everytime).
And on the other hand, the background.js doesn't require that much memory or performance, it just have a simple listener for storage issues.
You did not get the sense of event pages.
The event page was listening for an event, and the event is dispatched.
A content script or other extension sends a message.
Another view in the extension (for example, a popup) calls runtime.getBackgroundPage.
If Battlelog is active, the event page can be active. If not, why should it be active? Only the content script calls the background page and the content script is only active when Battlelog is.
Well, i just give it a try but i don't expect that this is working well.
It should work fine. The "background" page goes live whenever a content script sends a message. It's the case, because the content script is indeed sending "messages" to store content.
Well, tested it right now.
Seems to work but i can't notice any memory or usage difference, weither in idle nor in use mode.
Anyway, things for clearing me up about this, never thought deeper about that.
You could just add it anyways for the next version, shouldn't hurt ^^