Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#3489 closed defect (fixed)

Firefox "restore last session" buttons missing

Reported by: RafaelLVX Assignee: trev
Priority: P1 Milestone: Adblock-Plus-2.7.2-for-Firefox
Module: Adblock-Plus-for-Firefox Keywords:
Cc: trev, erikvold, sebastian, greiner, mapx Blocked By:
Blocking: Platform: Firefox
Ready: yes Confidential: no
Tester: Ross Verified working: yes
Review URL(s):

https://codereview.adblockplus.org/29336300/

Description

Environment

Windows 10 1511 64 bit
Firefox Developer Edition 64 bit 45.0a2 (2016-01-07)
Adblock Plus 2.7
Filters irrelevant I suppose

How to reproduce

When Firefox closes abruptly (like when I kill the Firefox process), later it opens and hails a "restore last session" screen.

Observed behaviour

Only when I have ABP activated, the buttons that actually restore the session do not display. If I do anything with the screen like resizing it, the buttons imediately appear. If I click on the empty space where I know one of the buttons should be, the invisible button does what it should. It's all working normally, except the buttons are invisible. It's really just a visual glitch.

I tried deactivating only ABP, it works as it should. I tried deactivating other add-ons and leaving only ABP activated, it glitches. I tried safe mode (all add-ons disabled), it works as it should.

Expected behaviour

Restore last session screen should have buttons at the bottom, one to restore and another not to restore anything.

Attachments (2)

glitch-firefox-adblockplus.png (54.4 KB) - added by RafaelLVX 4 years ago.
Screenshot
testpolicy-1.0.xpi (2.1 KB) - added by trev 4 years ago.
Minimal extension triggering the issue

Download all attachments as: .zip

Change History (17)

Changed 4 years ago by RafaelLVX

Screenshot

comment:1 Changed 4 years ago by mapx

  • Cc trev erikvold sebastian greiner mapx added
  • Component changed from Unknown to Adblock-Plus-for-Firefox

comment:2 Changed 4 years ago by trev

@OP: What if you type about:sessionrestore into the address bar, does the page opening then have this issue as well?

For reference, I tried Firefox 43, 44, an older Firefox 45.0a1 nightly and the current Firefox 46.0a1 nightly. All that on Windows 7, I don't have Windows 10 - but it shouldn't really matter. The issue isn't reproducible for me. It might be related to filters, but in theory no filters should be applying on that page.

Last edited 4 years ago by trev (previous) (diff)

comment:3 Changed 4 years ago by mapx

I can reproduce the issue in 45.0a2, even "disabling everywhere".
I use "show my windows and tabs from last time" setting.

Last edited 4 years ago by mapx (previous) (diff)

comment:4 Changed 4 years ago by mapx

when I type about:sessionrestore all it's ok

comment:5 Changed 4 years ago by trev

Ok, now I could reproduce it as well. It's some kind of drawing issue, hovering over the buttons brings them back.

comment:6 Changed 4 years ago by trev

@erikvold: Frankly, I have no idea how to go from here. I can trigger this by restoring contents of sessionCheckpoints.json and sessionstore-backups/recovery.js in the Firefox profile, this allows me to reproduce the issue relatively easily. I could confirm that it is somehow related to Adblock Plus, reproducible ~50% of the time in Nightly. However, I cannot reduce the problem because it's only visible in about:sessionrestore when it shows up on startup. I put the exact same page into an extension (with fixed session data) - no issue there, even when that page shows up on startup. Any ideas?

comment:7 follow-up: Changed 4 years ago by trev

This seems to be related to the sync IPC call in our nsIContentPolicy.shouldLoad implementation - if I remove that call the issue goes away, adding another sync message instead brings it back. That's regardless of whether E10S is actually switched on. This is similar to us breaking Ghostery pages a while ago (I think Ghostery worked around that issue somehow). The issue is clearly somewhere in Mozilla's codebase but pinpointing it seems close to impossible.

comment:8 in reply to: ↑ 7 ; follow-up: Changed 4 years ago by erikvold

Replying to trev:

This seems to be related to the sync IPC call in our nsIContentPolicy.shouldLoad implementation - if I remove that call the issue goes away, adding another sync message instead brings it back. That's regardless of whether E10S is actually switched on.

This might indicate a platform bug, maybe a more simple add-on for test purposes would be helpful. If it shows the same issue then it is a platform bug, if it does not, then it might be something else in abp.

This is similar to us breaking Ghostery pages a while ago (I think Ghostery worked around that issue somehow). The issue is clearly somewhere in Mozilla's codebase but pinpointing it seems close to impossible.

Which bug was this?

Changed 4 years ago by trev

Minimal extension triggering the issue

comment:9 in reply to: ↑ 8 Changed 4 years ago by trev

Replying to erikvold:

This might indicate a platform bug, maybe a more simple add-on for test purposes would be helpful. If it shows the same issue then it is a platform bug, if it does not, then it might be something else in abp.

I attached a minimal extension, it does nothing beyond registering a content policy in the child process and sending a sync message from nsIContentPolicy.shouldLoad. That's already sufficient to reproduce the problem.

Which bug was this?

I don't think this was ever filed. The Ghostery guys asked us about it and then somehow worked around it on their end.

comment:10 Changed 4 years ago by trev

  • Resolution set to invalid
  • Status changed from new to closed

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1247640 - it seems that we cannot do anything else on our end, this appears to be a platform bug and up to Mozilla now.

comment:11 Changed 4 years ago by trev

  • Priority changed from Unknown to P1
  • Ready set
  • Resolution invalid deleted
  • Status changed from closed to reopened

I realized that there is a simple work-around for this issue, reopening.

comment:12 Changed 4 years ago by trev

  • Owner set to trev

comment:13 Changed 4 years ago by trev

  • Review URL(s) modified (diff)
  • Status changed from reopened to reviewing

comment:14 Changed 4 years ago by trev

  • Milestone set to Adblock-Plus-for-Firefox-next
  • Resolution set to fixed
  • Status changed from reviewing to closed

comment:15 Changed 4 years ago by Ross

  • Tester changed from Unknown to Ross
  • Verified working set

Could not reproduce the demonstrated issue (testpolicy-1.0.xpi attachment) with/in the latest ABP.

ABP 2.7.2
Firefox 38.0 / Firefox 46.0a1 (Nightly) / Ubuntu 14.04 x64
Firefox 38.0 / Firefox 43.0.1 / Firefox 46.0a1 (Nightly) / Windows 7 x64

Note: See TracTickets for help on using tickets.