Closed
Bug 1366091
Opened 7 years ago
Closed 7 years ago
Voltage SecureMail (HPE SecureMail) is broken in nightly when email message loaded as file: URL
Categories
(Core :: General, defect)
Core
General
Tracking
()
VERIFIED
DUPLICATE
of bug 1351358
People
(Reporter: dbaron, Unassigned)
References
Details
Attachments
(1 file)
243 bytes,
text/html
|
Details |
Voltage SecureMail, which is a product described at https://www.voltage.com/products/email-security/hpe-securemail/ , is broken in nightly but not in beta. However, based on bisecting, it's been broken in nightly for quite a while, since this one day range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bad312aefb42982f492ad2cf36f4c6c3d698f4f7&tochange=f8f4eaac1701107f794b48891bcca2c95d39d503 My steps to reproduce are: * load the HTML email (launched from my email client) in Firefox as a file: URL * click the [Click to Read Message] button Actual results: Page showing: > [company name] SecureMail Error > There was a problem servicing your request. Please try again later. > > Click here for additional information. > > Error Code: 23 Expected results: Page showing: > [SECURE DOCS] > > Create a password to continue > > Full Name > [etc...]
Reporter | ||
Comment 1•7 years ago
|
||
Toggling the preference "browser.tabs.remote.separateFileUriProcess" to false fixes it.
Reporter | ||
Comment 2•7 years ago
|
||
Regression from the pref added in https://hg.mozilla.org/mozilla-central/rev/fe6ea50bfb38e8e9a93408a5f9b3c26082073ecb
Blocks: 1147911
Flags: needinfo?(bobowencode)
Reporter | ||
Updated•7 years ago
|
Summary: Voltage SecureMail is broken in nightly → Voltage SecureMail (HPE SecureMail) is broken in nightly when email message loaded as file: URL
Reporter | ||
Comment 3•7 years ago
|
||
The thing that this the HTML that's loaded at a file: URL is doing is that it has a <form method="post"> to post to an https: URL, with about 2 megabytes of data in a series of 761 <input type="hidden"> elements (plus a few other <input type="hidden"> with metadata, plus the single <input type="button"> to submit the form.
Reporter | ||
Comment 4•7 years ago
|
||
(I suspect this may have something to do with the size of the POST data involved being sent over IPC...)
Reporter | ||
Comment 5•7 years ago
|
||
Actually, I think this has nothing to do with the size -- it seems like we're turning POSTs into GETs incorrectly. I'll attach a testcase using a public site.
Reporter | ||
Comment 6•7 years ago
|
||
This posts to the post endpoint of https://httpbin.org/ . If it works correctly, you'll see a visual representation of the JSON results. If it fails, you'll see: > Method Not Allowed > > The method is not allowed for the requested URL.
Reporter | ||
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 8•7 years ago
|
||
And I've confirmed that this is fixed when I update my tree to mozilla-inbound from a few hours ago (with the changes from bug 1351358).
Status: RESOLVED → VERIFIED
Updated•7 years ago
|
Flags: needinfo?(bobowencode)
Updated•6 years ago
|
status-firefox57:
affected → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•