Opened on 01/09/2015 at 01:50:38 PM
Closed on 01/13/2015 at 02:20:06 PM
Last modified on 01/13/2015 at 05:53:55 PM
#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)
Environment
chrome 39, 40
ABP 1.8.9
How to reproduce
- create a spreadsheet on google drive
- Go to "File" -> "Print"
- 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:
https://adblockplus.org/forum/viewtopic.php?f=10&t=27282
Attachments (0)
Change History (8)
comment:1 Changed on 01/09/2015 at 03:04:44 PM 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 on 01/09/2015 at 05:46:07 PM by sebastian
- Cc trev greiner added
comment:3 Changed on 01/09/2015 at 06:42:30 PM 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 on 01/09/2015 at 07:50:56 PM 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 https://crbug.com/416907.
comment:5 Changed on 01/10/2015 at 11:54:03 AM 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 docs.google.com 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 on 01/11/2015 at 08:36:53 AM by mapx
- Cc Paddy Landau added
comment:7 Changed on 01/13/2015 at 02:20:06 PM 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 on 01/13/2015 at 05:53:55 PM by sebastian
- Owner set to sebastian
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 docs.google.com 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?