Closed Bug 417715 Opened 12 years ago Closed 12 years ago

Uploading pictures to Ebay is not possible with Firefox 3 Beta 3

Categories

(Tech Evangelism Graveyard :: German, defect, P1, major)

x86
Windows Vista

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: thorsten, Assigned: nkhanna)

References

()

Details

(Keywords: regression, testcase)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3

Since I upgraded to Firefox 3 Beta 3 it is not possible anymore to upload pictures to Ebay.

When you visit URL http://cgi5.ebay.de/ws/eBayISAPI.dll?EasyLister&keywords= and go to step 3 and try to upload a picture an error message appears.

At the moment I have to use IE, when I want to sell something on ebay, because Firefox is not working for this task. It is really frustrating !

Reproducible: Always

Steps to Reproduce:
1. Visit the URL http://cgi5.ebay.de/ws/eBayISAPI.dll?EasyLister&keywords=
2. Go to step 3 and click on button "Foto hinzufügen"
3. In the popup dialog search for a picture on your harddisc
4. When you click on "Foto hochladen" the error message appears



In Firefox 2 this functionality worked without problems.
Since I upgraded to Firefox 3 this is not working anymore and I have to use IE when I want to sell something on ebay.
Flags: blocking-firefox3?
Version: unspecified → Trunk
I can confirm this bug with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008021504 Minefield/3.0b4pre ID:2008021504 but it doesn't happen under OS X.

The error message which comes up states that the selected image cannot be found on the computer. When the pop-up is opened I see following error within the Error Console:

Error: this.editor is null
Source File: chrome://global/content/bindings/textbox.xml
Line: 152
Status: UNCONFIRMED → NEW
Component: General → Widget: Win32
Ever confirmed: true
Flags: blocking-firefox3?
Keywords: regression
Product: Firefox → Core
QA Contact: general → win32
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Priority: P2 → P1
Can someone hunt down a one-day regression range?

It happening on Windows but not Mac is just bizarre....
Does this happen for any filename and any directory? If it's windows-specific I wonder if it's related to unicode file paths being converted to native at some point in the process (which is lossy).
The regression happens between the following two trunk nightly builds:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007111404 Minefield/3.0b2pre ID:2007111404

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007111505 Minefield/3.0b2pre ID:2007111505

I tried with several file types but without success.
Bug 143220, perhaps?  The platform difference could be something in the site code...

The other option is bug 324397 (easy to test by flipping the pref back).

Those two are the only things in that range that look to me like they might affect this.
Flipping the pref back to 0 doesn't change anything for me. If we would have a test case that works under OS X I could try to debug. But bug 143220 sounds like a good candidate. Perhaps an issue in handling the path delimiters '/' or '\'? 
Looking for an owner for this bug.  Anyone?
I can take a shot at it.
Assignee: nobody → dholbert
(In reply to comment #6)
> Bug 143220, perhaps? 

(In reply to comment #7)
> But bug 143220 sounds
> like a good candidate. 

Yup -- backing out the patch for bug 143220 fixes this bug on Windows Vista.
Blocks: 143220
Status: NEW → ASSIGNED
Daniel, is the page actually getting the value and doing something with it, perhaps?  If it _is_ calling that getter, what's the JavaScript stack look like when it does that?
As Boris suggested in Comment 6, the windows-specific aspect of this bug is in their JS code.

See this chunk from easylister_dlg_photos_e5511de.js, where "val" is the user-provided filename:
(whitespace added for readability) 

  if(!this.oGlobals.oClient.bMac &&
     !this.oGlobals.oClient.bLinux &&
     ( (val.lastIndexOf("\\")==-1) ||
       ((val.indexOf(':')!=1) && (val.indexOf('\\\\')!=0) )))


    this.parent.setErrMsg("FP001");
 else 
{
   this.enable(false);
   oPicForm.setAction(sMSAUrl);
   oPicForm.submit();
 }

The "setErrMsg" is what triggers the buggy state, whereas the "else" clause is what gives correct behavior.

The "if" conditions basically puts the following requirements on Windows paths, while placing no restraints on Mac/Linux paths:
  - Must have at least one '\' character
  - Must either contain ':' or start with \\

After the checkin of bug 143220, we only give the file's name, without any path information, so those conditions don't hold anymore.  So, that JS code will always fail on Windows platforms.
Redirecting to evangelism.  Ebay's script seems to assume we're giving them the full path to the file, and we no longer do that. (nor should we, per bug 143220)


Assignee: dholbert → english-us
Status: ASSIGNED → NEW
Component: Widget: Win32 → English US
Flags: blocking1.9+
Product: Core → Tech Evangelism
QA Contact: win32 → english-us
Version: Trunk → unspecified
Thanks for driving this, Daniel.
What is the normal procedure for such bugs? Will Ebay be informed about this issue? 
The more people inform them, the better, generally...
(In reply to comment #15)
> What is the normal procedure for such bugs? Will Ebay be informed about this
> issue? 
> 

There is no longer an official tech evangelism team and all contacts are made by members of the community. To paraphrase an old mozilla developer adage: "emails to deficient sites appreciated". If you want to make sure ebay knows about this, you should contact them and report back here.

I've cc'd some @ebay.com folks I found in bugzilla. Maybe they can report this to the appropriate people or give us some contacts.
I've also sent a message via the contact form to Ebay Germany, pointing to both bug reports.
Seems nothing is happening on this problem ?
> Seems nothing is happening on this problem ?

It's a problem in Ebay's code: they were relying on a security hole, and that hole got fixed.  Please contact them if you want this to get resolved...
Well,
can't believe that. With FX2 it worked :-)
Why should it be an Ebay problem then.

If it works for FX2 and with FX3 not.
As bz said: "they were relying on a security hole, and that hole got fixed".  Telling us to re-open the security hole will not be productive; you should contact eBay if you can, and not further comment here about the specific change.  Thanks!
Notified to the team at ebay that owns this code. It's been either addressed already or being looked at now.

Thanks
Thorsten, dholbert: do either of you know if eBay has fixed their code yet? We'd like to take bug 143220 on the FF2 branch.
Brandon can upload photos to the _us_ site using FF3b5, does that mean it's fixed or did the German version use different code?
(In reply to comment #24)
> Thorsten, dholbert: do either of you know if eBay has fixed their code yet?
(In reply to comment #25)
> did the German version use different code?

I don't know -- in my analysis on this bug, I just worked with the zipped testcase that's attached here.  (I don't actually have an ebay account.)
Yes it has been fixed by eBay.
Hello,
I reported that bug in the past and I just checked it with Firefox 3.0 RC1.

It works now.

So this bug can be closed !
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Verified with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0 ID:2008051206
Status: RESOLVED → VERIFIED
Component: English US → German
Thanks for reporting back to us, and thanks to the ebay employees who helped fix the experience for FF3 users.
Assignee: english-us → nkhanna
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.