Closed
Bug 1368248
Opened 8 years ago
Closed 8 years ago
Weird tabbrowser session-reload behaviour after fixing bug 1366643
Categories
(SeaMonkey :: Session Restore, defect)
SeaMonkey
Session Restore
Tracking
(seamonkey2.51 unaffected, seamonkey2.52 affected)
RESOLVED
DUPLICATE
of bug 1466911
Tracking | Status | |
---|---|---|
seamonkey2.51 | --- | unaffected |
seamonkey2.52 | --- | affected |
People
(Reporter: tonymec, Unassigned)
References
Details
Attachments
(1 file)
106.69 KB,
text/plain
|
Details |
- I'm not sure anyone can reproduce my problem but if I don't state it it won't be cured.
- Not sure if this belongs in "Tabbed Browser" or in "Session Restore": I flipped a coin but it fell on the edge. :-P
tl;dr: if you can't stand verbose problem descriptions, see the summary description near the bottom of this comment.
I have an extremely big session (549 tabs at the moment, which I reload "on demand", i.e. browser.sessionstore.max_concurrent_tabs is set to 0). In Mozilla-built nightlies until 12-May it reloaded normally after shutdown and restart, all favicons became quickly visible in my multirow tab bar (thanks to userChrome.css) and any tab made current started loading immediately.
Then it started crashing at every startup due to bug 1363036; but frgrahl's home build mentioned in bug 1363036 comment #19, which was online only for a short time, made it behave normally again. OTOH, Bill Gianopoulos's build made in bug 1366643 comment #13 and tested by me in bug 1366643 comment 21 already had this weird behaviour (see at bottom) but it didn't crash, so I thought, "What the hell, at least the crash is gone, let's wait until Samael Wang fixes bug 1363036 before raising problems that may disappear". However, now bug 1363036 and bug 1366643 are both RESOLVED FIXED and I'm left with the following quirks:
Summary description of the problem
----------------------------------
- At startup session restore, only very few tabs get a favicon other than the default "no favicon found" one.
- Clicking one of the few tabs with a favicon (or one of the even fewer ones which would get a favicon if one were defined) makes it load immediately, but clicking one of the other ones displays a blank page which doesn't start loading. Clicking the Go button makes the page load.
- The W3C site is one of the very few for which I don't need to click the Go button. Is it because it validates flawlessly (0 errors, 0 warnings) according to the "HTML Validator" extension's double validation (both Tidy-style and W3C-syle), which is not the case of (for instance) bugzilla.mozilla.org? But no: there are pages written by me on my home site which also validate flawlessly, but they need a "Go button kick".
- The tab which was current at shutdown (and becomes current again on restart) always starts loading immediately.
- This reminds me of bug 1334780. Might it have come unstuck, at least partly?
Known bad:
----------
UA:"Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 SeaMonkey/2.52a1"
ID:20170527011755 en-US
c-c:49a68316ebabe052b42cee27985fdbc1015feb45
m-c:ebad93e117700d8e2d65573b824beb18a8cc2030
This is the first hourly after a "no building" period of several days, and before that my session crashed starting on 13 May, so the "last known good" which I can ascertain is the following:
Known good:
-----------
20170512003001
https://hg.mozilla.org/comm-central/rev/da9448c4bf4f25d4b3a7aabed34576958f8ce2fa
https://hg.mozilla.org/mozilla-central/rev/8a7d0b15595f
More info
---------
N.B. Pasting the attachment from the "Browser console". I think the "Error console" only starts recording when I open it (I find it empty) which is useless for a startup bug.
Reporter | ||
Comment 1•8 years ago
|
||
P.S. Happens also in Safe Mode: a few more favicons are visible, but where they aren't (which is the grreat majority) I also see a blank page on clicking the tab, there is no visible Go button (it has gone back into the button palette) and clicking the empty space at the end of the URL bar followed by hitting Enter makes the page load.
Reporter | ||
Comment 2•8 years ago
|
||
Oh, one more quirk: after going to Safe Mode and back, W3C tabs need a Go kick but MDN ones, and the ones to their right for a total of 20, don't.
BTW: All tabs' width set to 18px (favicon only) by userChrome.css. My userChrome.css can be seen at http://users.skynet.be/antoine.mechelynck/other/userChrome-seamonkey.css
Reporter | ||
Comment 3•8 years ago
|
||
After saving the full session to the Homepage and loading the homepage (which forces loading all tabs and takes all my RAM plus some of my swap), the next saved session is normal again — until next time. I wonder what really happened down inside.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Comment 4•6 years ago
|
||
Comment 3 indicates that this is the same problem as bug 1466911.
Resolution: INCOMPLETE → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•