I've noticed that my pinned bugzilla tabs sometimes get session-restored with an offset between the top-header-bar and the top of the page. The issue goes away after I interact with the page (e.g. if I scroll down), but it comes back on my next session when the tab gets session-restored again.

I've come up with a reduced testcase and session-restore file that reproduces the issue. It seems to have to do with this snippet of the sessionstore JSON:

                            "presState": [
                                {
                                    "stateKey": "0>html>1",
                                    "scroll": "0,1000"
                                }
                            ]
                        }
                    ],
                    "scroll": {
                        "scroll": "0,200"
                    }

I think (?) the second scroll value encodes the document scroll position, and the first one encodes an additional scroll offset which apparently mis-positions the fixed-pos element, in a way that persists even after I interact with the page (fixing the issue) and then restart Firefox (which makes the issue come back).

The "presState" object seems to correspond to https://searchfox.org/mozilla-central/source/layout/base/nsILayoutHistoryState.idl , so I'm initially filing this as a layout bug.

I'm willing to believe that my sessionstore file here can be considered semi-bogus (I don't know how this secondary scroll offset got in there in the first place), but I would expect that we'd be able to correct it when we round-trip through a user interaction and a re-serialization of the session

Here's what this looks like, in a pinned bugzilla tab. Notice the space between the Bugzilla header-bar and the top of the viewport.

STR:

1. Create an empty folder (say, /tmp/foo), which we'll use as your profile folder.
2. Copy this bug's sessionstore.jsonlz4 file into this folder.
3. Start Firefox, using this folder as your profile.

Here are commands for steps 1-3:

mkdir /tmp/foo && \
  cd /tmp/foo && \
  curl -o sessionstore.jsonlz4 https://bug1753279.bmoattachments.org/attachment.cgi?id=9261966 && \
  firefox  -profile /tmp/foo -no-remote

4. Wait for the first pinned tab to finish loading (the throbber disappears), and then switch to it.
5. Scroll the page.
6. Restart Firefox, and again wait for the first pinned tab to finish loading, and then switch to it.

ACTUAL RESULTS:

• In step 4, you'll see testcase 1 with an invalid rendering -- the header is positioned at a small distance from the top of the viewport (orange is visible above it).
• Step 5 fixes this.
• ... but in step 6 (after a restart), the issue comes back.

EXPECTED RESULTS:
Ideally no such invalid layout in step 4 or 6. (Step 6 in particular, since we've gotten a chance to round-trip and regenerate/reserialize the scroll state, I assume.)

sorry, attached the wrong sessionstore file before (from a different fresh profile). Here's the correct one.

For convenience, here's the raw JSON that's encoded/compressed in my attached sessionstore.jsonlz4 file. (I've been using https://addons.mozilla.org/en-US/firefox/addon/mozlz4-edit/ to convert JSON into/out-of JSONLZ4.)

I confirmed that tnikkel's patch in bug 1742241 fixes this.

My STR from comment 3 produce EXPECTED RESULTS in a build with that patch. (No unexpected offset in step 4 or step 6.)

For what it's worth, I just hit what-looks-like this exact bug in Firefox Nightly 118.0a1 (2023-08-17). I switched tabs to a Bugzilla tab, and the header for that tab was offset from the top of the page (nearly halfway down the viewport, in fact), with just bugzilla's dark background color for the area above it. It looked similar to the screenshot in comment 1, except with the fixed header even further down the page. (I think the exact distance isn't super relevant; I recall repro'ing this bug with varying difference back when I hit this regularly and filed this bug.)

A single mousewheel-scroll tick fixed the issue, making the header snap back to the top of the page and the content look correct (no blank areas).

I don't think the tab in my case today was "sessionstore"-restored -- it's a tab that I opened and was interacting with during this same Firefox session. (Though I hadn't switched to it for tens of minutes, I think; so it's possible it went into some form of dormancy.)

The patches I landed in bug 1742241 and around that time fixed the most common cases of this happening. However I know that they did not fix all of them since I still saw the "bugzilla headers moved down" bug sometimes after those patches landed. Recently I haven't seen this bug but I don't think thats because the bug was fixed; I think more likely it still exists I just haven't come across it. Also possible is that I have apz.paint_skipping.enabled disabled which might avoid the bug. It's good to keep on eye on this bug in case the frequency increases.

(In reply to Timothy Nikkel (:tnikkel) from comment #9)

Also possible is that I have apz.paint_skipping.enabled disabled which might avoid the bug. It's good to keep on eye on this bug in case the frequency increases.

(I have apz.paint_skipping.enabled at its default true value on the machine where I encountered comment 8, FWIW.)