1879216 - Port bug 1875100: RAM usage grows too much on minimized browser window with sidebar panel containing APNG background

Status: RESOLVED FIXED

(Thunderbird :: Upstream Synchronization, defect)

Comment 1

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1879216 - Temporarily stop setting `.docShellIsActive` to avoid assertion failures. r=#thunderbird-reviewers

These calls are failing at https://hg.mozilla.org/mozilla-central/rev/22c6ddd752f4#l7.92 because the browsers aren't top-level.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/e514b637bb34
Temporarily stop setting .docShellIsActive to avoid assertion failures. r=mkmelin

Comment 3

[Emilio Cobos Álvarez [:emilio]]

Ah, sorry, didn't realise TB was messing with activeness too. Lmk if I can help.

Comment 4

[Geoff Lankow (:darktrojan)]

You can. We're failing at BrowsingContext::CanSet, I think because we're making chrome browsers active/inactive, and they're not at the top of the tree. I guess the criteria needs to be changed somehow.

There's also an assertion failing at CanonicalBrowsingContext::SetIsActive, probably for the same reason, but I haven't even begun to look at it yet.

(We're doing this so that a message displayed in a background tab doesn't get marked as read until the tab becomes the foreground tab. I think it's a good approach but if you've got better ideas it could be changed.)

Comment 5

[Emilio Cobos Álvarez [:emilio]]

Can those be top level (type='content') instead? You also need manualactiveness="true" now.

Comment 6

[Magnus Melin [:mkmelin]]

Attachment: backtracestac

Seems they are `type='content'` already https://searchfox.org/comm-central/rev/bb2d37dc56cc4aa8cbcbe0f7e7a77c79c0b1a88b/mail/base/content/aboutMessage.xhtml#130,138

I tried adding I tried adding manualactiveness="true" but still doesn't work.

Comment 7

[Magnus Melin [:mkmelin]]

Oh, I guess that's not the one, but the about:message and about:3pane ones.
https://searchfox.org/comm-central/rev/bb2d37dc56cc4aa8cbcbe0f7e7a77c79c0b1a88b/mail/base/content/about3Pane.xhtml#341
https://searchfox.org/comm-central/rev/bb2d37dc56cc4aa8cbcbe0f7e7a77c79c0b1a88b/mail/base/content/messenger.xhtml#566

But adding type="content" manualactiveness="true" will need other adjustments. I'm not sure how easy that would be. Geoff probably has a better idea about that.

Comment 8

[Geoff Lankow (:darktrojan)]

The short answer is "no". We tried to make them content when developing them and ran into too many roadblocks. I can't recall what off the top of my head, but I know that using chrome browsers was a decision not an oversight.

Comment 9

[Emilio Cobos Álvarez [:emilio]]

It'd be nice to know which roadblocks? The current code you were using isn't great because you're not handling top level document visibility...

Comment 10

[Geoff Lankow (:darktrojan)]

I think the big one was handling web content inside local content, getting with message managers to do what we want, etc.. Some of the issues have probably gone away in the 2+ years since, but tried today and I know there's still some problems I don't want to have to solve for a second or third time.

Anyway, regarding this particular bug, I have a solution. We don't actually need to set the activeness of the chrome browsers, just the content browser that displays messages. We can figure out if we're in a background tab some other way.

Comment 11

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1879216 - Only set `docShellIsActive` on content browsers. r=#thunderbird-reviewers

We're only using it to prevent messages in background tabs being marked as read, but the Page
Visibility API will now apply to all tab types that contain a content browser.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/81c7b19049f1
Only set docShellIsActive on content browsers. r=mkmelin