Iframe based AJAX call blocked by popup-blocker or opening in new tab

Iframe based AJAX call blocked by popup-blocker. After allowing popups, form submits to new tab instead of hidden iframe.

Issue appeared in TBB 5.5. TBB 5.0.7 (previous stable) works with same code normally.

To reproduce go to http://dmirrgetyojz735v.onion/d/#set-lang:en and try to make post with JS support enabled. Code of submit and AJAX handlers can be found in http://dmirrgetyojz735v.onion/js/tinaib1.js , seek doPostForm func.

Trace is like

WARNING: content window passed to PrivateBrowsingUtils.isWindowPrivate. Use isContentWindowPrivate instead (but only for frame scripts).
pbu_isWindowPrivate@re[/gre/modules/PrivateBrowsingUtils.jsm:25:14](/gre/modules/PrivateBrowsingUtils.jsm:25:14)
nsBrowserAccess.prototype.openURI@chrome://browser/content/browser.js:15194:21

Depending of the exact code, call stack may contain func, which actually submitted form.

Tested on Ubuntu 14.04 x64.

Trac:
Username: sky_kohai

added TorBrowserTeam201602 TorBrowserTeam201602R component::applications/tor browser owner::mcs priority::high reporter::sky_kohai resolution::fixed severity::major status::closed tbb-5.5-regression tbb-usability-website type::defect labels

I can reproduce this and it seems we have more users with similar problems (see e.g.: https://blog.torproject.org/blog/tor-browser-55-released#comment-153779) I am wondering what is causing this. One quick revert of Torbutton to 1.9.3.7 did not show a difference.

Trac:
Severity: Normal to Major
Priority: Medium to High
Cc: N/A to mcs, brade, arthuredelstein

5.5a4 is the first alpha that breaks. Looking at the intersection of bugs that both got fixed in this alpha and in 5.5 stable this leaves us with #16620 (moved), #17351 (moved) and the font bugs closed in the alpha.

Reverting Torbutton to 1.9.3.7 should take #17351 (moved) out of the loop and the Torbutton portion of #16620 (moved). Seems the tor-browser patch for #16620 (moved) and the font bugs are left.

Okay, 95a62d13e045b950ed2b2f242da7413d33386a47 seems to be the culprit. Backing that one out from tor-browser-38.3.0esr-5.5-2 leads to a working Tor Browser while leaving the commit in leads to the issue on this bug. mcs, brade: could you take a look at it?

Trac:
Status: new to assigned
Owner: tbb-team to mcs

Kathy and I did not try a post to ​http://dmirrgetyojz735v.onion/d/#set-lang:en because we are not sure where to post without annoying real users of that site. But we created our own test case based on the JS code and were able to reproduce the problem.

The root cause is that the hidden iframe initially loads about:blank, and since there is no referrer at that point the #16620 (moved) code clears the iframe's window.name. We are working on a fix, which most likely will involve never clearing window.name when about:blank is being loaded (the old Torbutton JS implementation included an exception for about:blank, but we thought it was only needed to handle new windows; apparently we were wrong).

Replying to mcs:

Kathy and I did not try a post to ​http://dmirrgetyojz735v.onion/d/#set-lang:en because we are not sure where to post without annoying real users of that site.

You should not worry about it. /d/ board is OK for testing. I also created special thread for tests. Feel free to use them if needed. ​http://dmirrgetyojz735v.onion/d/res/133826.html#set-lang:en

Trac:
Username: sky_kohai

Replying to sky_kohai:

You should not worry about it. /d/ board is OK for testing. I also created special thread for tests. Feel free to use them if needed. ​http://dmirrgetyojz735v.onion/d/res/133826.html#set-lang:en

Thanks! Kathy and I prepared a fix which includes a regression test: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug18168-01&id=179c9bfd56d3146c7d8f5ab6b6389010e1a570de

Tor Browser developers: please review.

Trac:
Keywords: N/A deleted, TorBrowserTeam201601R added
Status: assigned to needs_review

I just saw https://blog.torproject.org/blog/tor-browser-55-released#comment-153806 and tested this page: http://www.tagindex.net/html/frame/example_t04.html with: network.http.sendRefererHeader = 1 network.http.sendSecureXSiteReferrer = false Unfortunately, the patch I posted a few minutes ago does not fix that regression. Kathy and I will work on a revised patch (I assume the root cause is related but I have not debugged this new scenario yet).

Trac:
Status: needs_review to needs_revision

http://news.gmane.org/gmane.linux.kernel seems to be another thing we should test against (via https://blog.torproject.org/blog/tor-browser-55-released#comment-153863).

Here is a new patch: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug18168-02&id=4a83eab098f0064fa8e1ce55b729dc42e0dd4058

Please review. We now avoid clearing window.name for all frames/iframes, which more closely matches the behavior of the original JavaScript implementation from Torbutton. Kathy and I tested this with all of the sites mentioned in this ticket and we added more automated tests, but more testing is welcome.

Trac:
Status: needs_revision to needs_review

Putting stuff on the radar for February.

Trac:
Keywords: N/A deleted, TorBrowserTeam201602 added

Carrying over review tickets.

Trac:
Keywords: TorBrowserTeam201601R deleted, TorBrowserTeam201602R added

This patch looks good to me. I inspected the code, ran the unit tests and tried out the examples.

This landed on tor-browser-38.6.0esr-5.5-1 (89226c03e3aed9c1ff3c740e0dcdcb0ac7e8e5ff) and tor-browser-38.6.0esr-6.0-1 (bc8af4dcdafd3de656bbff245eb70a0025829b90), thanks.

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

Trac:
Keywords: TorBrowserTeam201602R deleted, TorBrowserTeam201602R tbb-5.5-regression added

closed

mentioned in issue #18172 (moved)

mentioned in issue #18172 (moved)

mentioned in issue #18188 (moved)

moved to tpo/applications/tor-browser#18168 (closed)