Closed Bug 1036433 Opened 10 years ago Closed 10 years ago

can't log into work.com in a remote tab

Categories

(Core :: General, defect, P2)

x86
macOS
defect

Tracking

()

RESOLVED DUPLICATE of bug 1043256
Tracking Status
e10s + ---

People

(Reporter: blassey, Assigned: mconley)

References

Details

When I try to log into work.com hitting submit returns me to the login page. However, after hitting submit if I shift-reload the page I'm actually logged in.
Assignee: nobody → mconley
Priority: -- → P2
Status: NEW → ASSIGNED
So piecing through all this GWT compiled JS took a while, but I think I know what's going on. There's a hidden iframe on the page that is the target of the authorization form, and there are event listeners on that iframe that read out the result of the document that it loads, and redirect / react based on that result. With non-e10s, the form submits, and the iframe POST's the user's credentials to https://app.work.com/j_spring_security_check. That 302's and redirects the iframe to one of two places https://app.work.com/authorized or https://app.work.com/unauthorized The authorized page contains the string "SUCCESS", and the unauthorized page contains the string "UNAUTHORIZED". The event listeners in the parent of the iframe listen for the load event, check those strings, and "do the right thing" based on those two possible states. With e10s, it seems this doesn't work. The iframe never fires the load event because the content at https://app.work.com/authorized and https://app.work.com/unauthorized cannot be read - it fails out with a "Content Encoding Error". STR: 1) Open up an e10s window 2) Browse to https://app.work.com/unauthorized ER: "UNAUTHORIZED" shown as content. AR: "Content Encoding Error The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression. Please contact the website owners to inform them of this problem."
Hey jduell, I'm not sure if you're the right person to ask, but do you have any idea why we might be hitting that content encoding error mentioned in comment 1 in an e10s tab, but not hitting it in a normal tab?
Flags: needinfo?(jduell.mcbugs)
This smells like either bug 1043256 or bug 1012917. I'm not going to dupe for now because I can't figure out which. We're jumping on bug 1043256, let's see if the fix for that solves this too.
Flags: needinfo?(jduell.mcbugs)
Depends on: 1043256
There is a preliminary patch for bug 1043256 which I just tested, and confirm that it fixes this bug.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.