854890 - Juniper Secure Access SSLVPN login relies on ID attribute on IFRAME setting content window's name - not spec compatible

Status: RESOLVED INCOMPLETE

(Web Compatibility :: Site Reports, defect)

Description

[Thomas Meyer]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130311191316

Steps to reproduce:

Hello,

I bisect a breakage of remote login to my companies site to this changeset:

Die erste fehlerhafte Revision ist:
Änderung:        110301:c350c6f28dd1
Nutzer:          Boris Zbarsky <[e-mail]>
Datum:           Mon Oct 15 14:00:09 2012 -0400
Zusammenfassung: Bug 799875.  Make the global scope polluter work even for qualified lookups.  r=jst

I'm using Fedora 18 and icedtea-web.x86_64 (1.3.1-3.fc18)

The remote login via the Juniper SSLVPN software works correctly in Firefox 18 and is broken in Firefox 19.

Juniper version is:
Juniper SSLVPN release [7.1.0] - build number [20169] build comment [R6]

Bisect log:
current e7208eeb05dacbba00bdf8e7631c7c0c5e8438a1
bad 5bb309998e7050c9ee80b0147de1e473f008e221
bad 95752d95cf73bde75446ba732d6fcf4387bacbb3
bad acf7f73e8b18d1400d690cda2c2ce470aa081a14
bad 557cfb0bdc396835d11d6d1f62316fbd92df96cf
bad 226cb9228a9e005da8769f28e655b3e05df44aac
bad a96deba7de41ab066810760a57ba414bb7341fb9
bad c350c6f28dd17652e01908cf38ab82f19029efb7
good fd72dbbd692012224145be1bf13df1d7675fd277
good 1dde5624fc81e8d98c493e6980b3fa80a6e48fa8
good d9e070c062f0dba3d724ec9f7cfc82f151dfd919
good 4e3c9bd6bd60783bd927eb7214c99f7807c83750
good 790a3878f22a8c795a833bc68e5480b895f9e757
good 7703f0ec6770271ae06a9bd2034f898439da4168
good 224fddb79a387bdb46eace136268ead5f7a99ae5
good ae20b1339bd6029664489b1ae7448431ff080464
good e7208eeb05dacbba00bdf8e7631c7c0c5e8438a1

Comment 1

[Thomas Meyer]

http://www.juniper.net/support/products/sa/7.1/

Comment 2

[Boris Zbarsky [:bzbarsky]]

Thomas, what does the relevant page's HTML and JS look like?  If you're not able to link to it directly, are you able to attach it here?

It sounds at first glance like the page is making incorrect assumptions about how the global scope polluter behaves, but it's hard to tell without seeing what it's actually doing.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Thomas says the code has this general structure:

  var win, doc;
  if (window.frames["xyz"]) {
    win = window.frames["xyz"]
  } else if (document.getElementById("xyz")) {
    win = document.getElementById("xyz").contentWindow;
  }

  if (win && win.document) {
    doc = win.document;
  } else {
    doc = defaultWin.contentDocument;
  }
  return doc;

If there is then an <iframe id="xyz"> in the DOM, this would have worked before and returned its contentDocument, but now will return defaultWin.contentDocument...

This is basically the same code pattern as in bug 843075...

Comment 4

[Boris Zbarsky [:bzbarsky]]

I filed https://code.google.com/p/chromium/issues/detail?id=347169 on Chrome and I think this is a tech evangelism issue, since we're following the spec here...

Comment 5

[Hallvord R. M. Steen [:hallvors]]

bz's bug is fixed in Chrome, it is now spec-compatible. I assume the Juniper login is now equally broken in latest Firefox, latest Chrome and latest Opera..

Thomas, still a problem?

Comment 6

[Mike Taylor [:miketaylr]]

It seems the reporter's account is inactive, so I'm gonna close this as INCOMPLETE. :/

Thomas, in case you do see this and can still answer Hallvord's question in Comment #5, please comment -- thanks!