Opened on 05/14/2014 at 10:23:53 AM

Closed on 05/14/2014 at 02:08:09 PM

Last modified on 10/08/2019 at 05:50:46 PM

#482 closed defect (duplicate)

Chrome: POST-form returning a PDF makes an additional GET request

Reported by: christiand Assignee:
Priority: P2 Milestone:
Module: Platform Keywords:
Cc: smultron45@gmail.com, trev, sebastian Blocked By:
Blocking: Platform:
Ready: yes Confidential: no
Tester: Verified working: no
Review URL(s):

Description

Environment

Mac OS X 10.6.8
Chrome 34.0.1847.137 (all other extensions disabled, all plugins disabled except "Chrome PDF Viewer")
Adblock Plus 1.8.1 (Filter EasyList Germany+EasyList)
Anti-virus software and other security software disabled

How to reproduce

  1. Open http://www.fondsnet.de/pdftest.php. It's a simple script creating a form with a submit button that makes a POST request. When submitting a simple PDF will be returned with MIME type application/pdf.
  2. Open the Chrome debugger tools, tab "Network".
  3. Click on the submit button.

Observed behaviour

The POST request will be send, it will wait for the response. So far as expected. But after fetching the response of the POST request, a GET request with the same URL will be sent discarding the first response. The Chrome viewer tries to render the HTML from the GET request and fails doing this.

Expected behaviour

The response of the POST request will be rendered with the internal Chrome PDF viewer.

Attachments (1)

screenshot_debugger.png (38.8 KB) - added by christiand on 05/14/2014 at 10:24:05 AM.

Download all attachments as: .zip

Change History (8)

Changed on 05/14/2014 at 10:24:05 AM by christiand

comment:1 Changed on 05/14/2014 at 10:25:48 AM by christiand

Additional note: the script doesn't make a redirect or such things.

comment:2 Changed on 05/14/2014 at 10:37:49 AM by philll

  • Owner set to arthur
  • Ready set

@Arthur: If deactivating all filter lists, the behaviour does not occur. Could you please check for affecting filters here?

comment:3 Changed on 05/14/2014 at 10:59:28 AM by mapx

  • Cc smultron45@gmail.com added

comment:4 Changed on 05/14/2014 at 12:59:02 PM by arthur

This doesn't seem to be a filter issue as Sebastian pointed out on IRC.

comment:5 Changed on 05/14/2014 at 01:25:59 PM by philll

  • Component changed from Unknown to Platform
  • Owner arthur deleted
  • Priority changed from Unknown to P2

comment:6 Changed on 05/14/2014 at 02:08:09 PM by sebastian

  • Cc trev sebastian added
  • Resolution set to duplicate
  • Status changed from new to closed

This happens when an extension creates a shadow root on the documentElement, in the response callback of a message sent to the background page. This is a Chrome bug and a duplicate of #450. Creating the shadow root immediately also fixes this issue.

Last edited on 05/14/2014 at 02:31:13 PM by sebastian

comment:7 Changed on 07/26/2019 at 01:19:22 PM by alicebolt

spam

Last edited on 10/08/2019 at 05:50:46 PM by kzar

Add Comment

Modify Ticket

Change Properties
Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none).
 
Note: See TracTickets for help on using tickets.