Yeah, this describes the same scenario. I fixed it as shown in my bug report. Btw, thanks for fixing.
I found another quirk (not sure if it is a bug) when working with iframes and using a parameterized EndURL. It seems that the encoding of the EnduRL is not consistent. I typed the URL encoded in, e.g. I used "&" and not a raw "&" as a parameter separator as this is the correct way of doing it (although most modern browsers will do this on-the-fly for you if they notice it's not correct). This worked well when you do not open the EndURL automatically. When I changed to open the EndURL automatically my application suddenly couldn't identify the parameters anymore. Which suggests that the EndURL gets encoded on submission, double-encoded in this case. I didn't check the code, though. I had to change my URL back to using just raw "&" although it would then create incorrect (but usable) links for the EndURL.
I think the encoding should be consistent, either it should get encoded by Limesurvey or not for both cases (presentation as a link or automatic opening of the EndURL). Shall I file a report on this?
