Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#1770 closed defect (fixed)

Can not print Google Drive spreadsheets

Reported by: mapx Assignee: sebastian
Priority: P2 Milestone: Adblock-Plus-1.8.10-for-Chrome-Opera-Safari
Module: Platform Keywords:
Cc: sebastian, trev, greiner, Paddy, Landau Blocked By:
Blocking: Platform: Chrome
Ready: yes Confidential: no
Tester: Verified working:
Review URL(s):

Description (last modified by sebastian)


chrome 39, 40
ABP 1.8.9

How to reproduce

  1. create a spreadsheet on google drive
  2. Go to "File" -> "Print"
  3. Click "Print"

Observed behavior

1.preview shows an empty page
2.print page ==> blank page

-no filter is triggered
-it happens even without any filter list
-you have to disable ABP to have a correct print process

reported in forum:

Change History (8)

comment:1 Changed 6 years ago by sebastian

  • Description modified (diff)
  • Priority changed from Unknown to P2
  • Ready set
  • Summary changed from ABP 1.8.9 - printing (google drive - spreadsheets) broken to Can not print Google Drive spreadsheets

comment:2 Changed 6 years ago by sebastian

  • Cc trev greiner added

It seems this is caused by creating the shadow root. When I remove the shadow DOM code, everything works fine. A while ago we had a similar issue (#450) with printing Gogle Drive spreadsheets, which made Chrome hang or crash instead. We worked around that issue by creating the shadow root earlier.

So far I don't have any better idea to fix this issue, than hard-coding the domain not using shadow DOM there. On the other hand this would also allow us to move the creation of the shadow root back into the the response callback, only creating a shadow root if there actually are some element hiding filters.

Any objections or better ideas?

comment:3 Changed 6 years ago by mapx

the user who reported the issue wrote:

" All this happened as far as I can see after the last update from January 6th. Before that we had no print problems."

so, probably with the last 1.8.9 it was some regression ?!

comment:4 Changed 6 years ago by sebastian

You are right, it's a regression introduced by #1703. Apparently the issue is caused by creating a shadow root for one of the frames there, which were ignored before due to

Last edited 6 years ago by sebastian (previous) (diff)

comment:5 Changed 6 years ago by sebastian

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

The frame in subject, embeds the spreadsheet as MS Excel file, using Google's PDF viewer plugin. This frame isn't visible, but used for printing the spreadsheet. Creating a shadow root there breaks printing, as described above.

There doesn't seem to be a way to generically detect scenarios like that. Also no sane website would do something like that. So I think it's reasonable (and the only option anyway) to skip shadow DOM on as suggested above.

However, it seems that we have to keep creating the shadow DOM (for other websites) before retrieving the element hiding selectors, to work around issues with CSS transitions (#452).

comment:6 Changed 6 years ago by mapx

  • Cc Paddy Landau added

comment:7 Changed 6 years ago by sebastian

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

comment:8 Changed 6 years ago by sebastian

  • Owner set to sebastian
Note: See TracTickets for help on using tickets.