Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong save format using inlinePrintOutput on chromium based browsers #504

Closed
cazitouni opened this issue Nov 14, 2023 · 5 comments · Fixed by qgis/qwc2#277
Closed

Wrong save format using inlinePrintOutput on chromium based browsers #504

cazitouni opened this issue Nov 14, 2023 · 5 comments · Fixed by qgis/qwc2#277

Comments

@cazitouni
Copy link

Using the inlinePrintOutput function to display the Atlas as a .pdf in the iframe works well, but there's an issue when attempting to save it using Edge/Chrome. It prompts to save it as an xml/json instead of a .pdf.

This functionality performs well on Firefox. Eliminating the targeting to the iframe in the form and opening it in a new tab displays the correct .pdf format when saving. Hence, it doesn't seem to be a content-type problem.

What might be a viable solution to this issue? Perhaps returning the Axios result used for non-inlinePrintOutput to the iframe instead of using the form's target option could be a potential solution. I can look into it eventually

Thank you in advance.
Best regards,
Clément.

@manisandro
Copy link
Member

manisandro commented Nov 14, 2023

This is an annoying (and actually pretty broken) behavior of some browsers, which re-download the PDF when clicking the save button, but they request the URL as GET when pressing the save button, meaning the request parameters submitted via POST are lost and hence the QGIS Server will return an invalid request XML. Happy to have any solutions for this...

@cazitouni
Copy link
Author

cazitouni commented Nov 14, 2023

@manisandro, I've found something, here , commit on my branch.
It's working good for downloading the file, only problem is that the file gets a random name, not the project one's.

I don't know if it looks like a good solution but it seems to works on my machine.
I can look more into it.

let me know your opinion,

Kind regards,
Clément,

@manisandro
Copy link
Member

Interesting! In my view this solution is already much better than the currently broken behaviour. Happy to accept a PR

@cazitouni
Copy link
Author

Nice, I'll look a bit more into it tommorow for file name and I make the PR.

I'll let you know.

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants