In bug 655649, which is now on Nightly and Aurora, we altered the semantics of document.domain to be more secure. In particular, if window A changes document.domain such that it is no longer same-origin with window B, cross-origin references will cease to function. Opera has the same behavior, and Hallvord (CCed) told me that they ran into a compat issue with ebay's non-flash image uploader. I have been unable to reproduce the issue, but he has verified the breakage in a Nightly Firefox build. We've been discussing this over email, but I think it's high time to switch the conversation to a bug. I think the first step is to get some help reproducing the issue, and then reach out to Ebay to try to get them to do something sane with document.domain.

The conversation thus far: Hallvord wrote: > A while ago, eBay's non-Flash image upload UI did rely on on getting references > to functions in another frame, setting document.domain and being able to call > said functions in spite of the now different security contexts. We gave them some > advice on using postMessage() instead, I need to recheck to see if they've > changed their code. > > (Re-tested. Yeah, they have been working on it but the postMessage() call is only > used if they detect Opera, and it's not actually working yet because they got the > "target origin" argument's syntax wrong (didn't include protocol), plus they seem > to have forgotten adding a message *listener* in the parent page..) > > FWIW, that's the only compat issue I remember having seen due to Opera doing more > security checks than what HTML5 specs. It's sufficiently bad to make us consider > our behaviour a bug, though for easily understandable reasons "be less secure" is > a class of bugs we're sort of reluctant to fix.. > > Well Bobby, at least you now know where to start testing if you add more security > checks to the DOM: eBay. > > https://twitter.com/#!/hallvord/status/165016007029694465 :) Bobby wrote: > Is Ebay still doing this? I just implemented the strict > document.domain semantics in Gecko and played around with creating a > listing and adding images - seems to work ok. If they are, can you > give me the script URL and repro steps? I'll try to get some muscle > behind this. :-) Hallvord wrote: > last time I looked they certainly were doing something like that, but it may > depend on browser sniffing and whatnot.. As far as I remember they have now added > a postMessage() mode while keeping the older code unchanged, and calling the > (not functional) postMessage() branch only in Opera. > > Try to make sure you get the non-Flash based upload functionality. I don't > remember if eBay lets you select that somewhere.. Bobby wrote: > I can't seem to reproduce the issue. Here's what I'm doing: > 0 - Disable flash > 1 - Log in > 2 - Go to "Sell item" > 3 - Select a category > 4 - Click 'add photo' and upload several photos. > > This all seems to work. Can you tell me how to reproduce the bug? I'd > like to start bugging them about this as soon as possible. Hallvord wrote: > you've gone the right route.. I'm not sure why you don't see the problem, > but I'll try to explain it in more detail.. > > We have a page from cgi5.ebay.com that submits a form to an IFRAME, > loading a response from for example msa-b1.cgi5.ebay.com. > > Parent sets document.domain to cgi5.ebay.com (though only in some browsers?!?): > if(oC.bMac||oC.bOpera)document.domain=document.domain; > Child also sets document.domain to cgi5.ebay.com, so it's allowed to talk > to parent. However, parent is no longer allowed to talk to its opener because > the popup has set document.domain explicitly while the opener hasn't. > > (Do you enforce the "must have set document.domain explicitly" rule?) > > What I'm seeing then is a security error when ebay.oDocument.oPage.updatePhoto() > calls this: > > function ebHTMLShow(pShow,pNoDisplayChange) > {var e=this.eElem;if(e) > {var s=e.style;if(s) > {s.visibility=pShow?"visible":"hidden"; > > this.eElem is a reference to the "Add a photo" button in the opener page, stored > since before the popup set document.domain. Trying to re-style this causes a > security error in Opera because the opener's DOM is now off-limits. Does this not > happen with your new implementation? Bobby wrote: > Thanks for the info. I've tried to reproduce the issue but I don't see it. So I > wonder if they've got some opera-specific code there? We do indeed enforce the > "must set document.domain explicitly" rule. > > The code has now landed in the Firefox nightly builds. If you have a second, > could you grab one ( http://nightly.mozilla.org/ ) and see if the same issue > arises? If not, that's probably good news for both of us - we avoid the compat > issue, and you tell ebay that they already have a version that works, and that they > just need to start serving it to your UA. :P Unfortunately I see uploading hangs in this nightly build, I had Firebug open an this is the console error message (I guess you're used to reading this and can tell I expanded some parts before copying): Hallvord wrote: > Error: Permission denied to access property 'parent' > onMSAResponse() easyli...17us.js (line 245)pUrl = > "http://i.ebayimg.com/00...1.JPG?set_id=8800004005" > pError = "" > pVersion = "2" > pIconUrl = "http://i.ebayimg.com/00...4.JPG?set_id=8800004005" > pMainUrl = "http://i.ebayimg.com/00...1.JPG?set_id=8800004005" > pIsMinPixel = "true" > pIsMinQuality = "false" > eval()242 (line 1) > ebObjectExecute() ebayba...17us.js (line 119)pFunction = "onMSAResponse" > eval()240 (line 1) > onload()basic.js (line 52) > {var oD=this.parent,oL=oD.parent.parent,oLP=oL.parent;if(!pUrl||(pUrl=="")) > easyli...17us.js (line 245) > > (This is just a few stack frames before the point Opera kills the same thread - > we're aligning security policies but seem to have arranged the actual checks > somewhat differently.).

However, I still don't see this when I create a listing and upload images (without flash) in a recent Nightly. Hallvord, which ebay locale are you using? I'm using en-us, which might explain the difference. FWIW I'm not sure about the language classification I gave in the bug. Evangelism folks, can someone try to figure out how to reproduce this?

AFAIK en-us (whatever ebay.com gives me by default) I was testing in 16.0a1 (2012-07-16)

I can reproduce on latest Nightly: http://hg.mozilla.org/mozilla-central/rev/812ea773f166 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 Only enabled addon being British dictionary. I can't even use the Flash uploader as a workaround, since they don't yet recognise Flash 11.4 beta :-(

Stormy, I'm kind of shooting in the dark here. Who's a good person to own this bug?

We really need to track this. Otherwise we're just going to ship it....

And again, for the record, I'm not convinced we want to be spitting into this wind. But oh, well.

Tracking in case we need to back out bug 655649 for FF16's release. Jean-Yves - are you the right person to own the TE outreach in this bug?

We may be OK with untracking this entirely if the Flash uploader is now working with Flash 11.4. With 99% of the web using Flash, this will likely have a very small affected population.

Alex - I'm unable to reproduce this with Flash 11,3,300,270 / Nightly. Tested and works as expected. I suggest we close.

(In reply to JStagner@Mozilla.com from comment #10) > Tested and works as expected. I suggest we close. The issue still exists (and was filed for) when flash isn't installed, so we shouldn't close it; but instead just consider whether it still needs to track. Note: The basic uploader still appears to people who have flash installed (and it will still be broken), it just isn't the default tab in the eBay UI, so many will not notice.

Ok, suggest we untrack.

(In reply to JStagner@Mozilla.com from comment #12) > Ok, suggest we untrack. I can understand that we might not want to block the release on this, but can we still reach out to them and ask them to use postMessage instead? It's not clear to me why there seems to be so much friction to doing that. Is there something going on behind the scenes that I'm not aware of?

Sure - I emailed two former associates at ebay. Both have left eBay but one forwarded the issue to his old team. I'll look into making a new contact there.

(In reply to JStagner@Mozilla.com from comment #14) > Sure - I emailed two former associates at ebay. Both have left eBay but one > forwarded the issue to his old team. > > I'll look into making a new contact there. Awesome, thanks! :-)

Agreed that we no longer need to track for release.

I ran into this issue when 16 released, as have others it appears. I've added some info to a support ticket on Ebay's public Q&A platform, including a reference to this bug. If the thread gets noticed by a dev then it stands a good chance of getting the issue fixed. Whether a dev sees it though is a different matter.

Link to that support ticket is http://answercenter.ebay.com/question/Technical-Issues/900351605

ebay seems to have addressed the issue on their side now & picture upload is working again with firefox 16.

(In reply to philipp from comment #19) > ebay seems to have addressed the issue on their side now & picture upload is > working again with firefox 16. Not on ebay.fr. If I use the simple form, the image uploader loads the image in infinite loop, same result if I use the detailed form, the classic image uploader loads in infinite loop, but not the standard Flash image uploader.

I have been experiencing this problem on Facebook and Creative Hotlist (where I upload to my portfolio). Firefox 16.0.2 Win 7 Ultimate I have no problem with these same uploads, using Explorer.

(In reply to Lizanne from comment #21) > I have been experiencing this problem on Facebook and Creative Hotlist > (where I upload to my portfolio). The issue as-reported in this bug is specific to Ebay - I'd be pretty surprised if it affected other sites. Did it stop working in Firefox 16? If so, it's probably worth filing another bug with steps to reproduce, and see if somebody can track down a regression range.

I don't know what the version release dates are but, I started having Facebook upload issues on October 19th. It happens when I try to UPLOAD a cover photo (instead of selecting one from photos I've already posted) and when I try to post a photo on another page (not my own). I thought this was just a Facebook glitch. Then, this past Wednesday, I had the same problem uploading images to my portfolio on Creative Hotlist. When I try to upload an image, I browse, select and submit ... and then it just spins and the upload never ends. I even wrote to their support team. Eventually I went to explorer and it worked perfectly. I then tried the uploads to Facebook with explorer as well and they also uploaded just fine.

> I don't know what the version release dates are See https://wiki.mozilla.org/RapidRelease/Calendar The last relevant release was October 9. Of course you may have actually updated to it a few days later....

Lizanne - Can you please file a separate bug? As I mentioned, this bug is specific to the Ebay issue, and your issue is unlikely to get any traction if you only report it here.

Are there any updates from ebay on this?

Anything new about this issue? We are getting another report of this in the following thread: https://support.mozilla.org/en-US/questions/954228

From the SUMO thread in comment 27, this is what ebay support has to say: > Hello Phillip, > > Thank you for writing to eBay in regard to not able to upload picture. > > Phillip,I can understand your disappointment due to this. I also confirm > that there is no such technical issue on the site. The issue that you are > facing is because of the Firefox 16 browser that you are using. This browser > has been launched recently and is still in the Beta (Development) phase and > that is why it may not support all features on a given site. > > I suggest that you kindly use Internet Explorer 8 or Firefox 3.6(not Safari or > Google Chrome as even they aren't compatible) or any other computer and > certainly you won't face any issues. We do hear similar issues from other eBay > members using Firefox 16.0 browser. You may be able to download lower version > and best compatible browser for eBay by going to the link mentioned below: > > http://anywhere.ebay.co.uk/ > > I trust this information is useful. Please write back to us if you need any > further assistance. > > Kind regards, > > Alan Nelson eBay Customer Support So Ebay support seems pretty clueless here (in particular, suggesting that Firefox 16 is a beta product and suggested Firefox 3.6, when in fact both of them are EOLed). Any contacts to get actual traction on this would be awesome.

I've this problem but in particular : only the ebay homepage is affected , being no displayed the images snippets , and only plain text links work , instead the rest , my bay and normal search work as well . Damn weird, help me .

I haven't seen any recent reports on this. Do we still have this issue?

So I suspect that everything related to ebay needs to be re-tested. The main reason is that ebay changed totally their platform a couple of months ago. Loic, do you still have the issue? If not let's close it as RESOLVE.

All works on ebay.fr. I tested: 1) Basic selling template: no issue with the unique image loader. 2) Advanced selling template: no issue with both standard (Flash) and classic image loaders.

Great, thanks for testing!