[PATCH]eBay Ipix images do not upload properly

VERIFIED FIXED in mozilla1.0



HTML: Form Submission
16 years ago
16 years ago


(Reporter: Lee Gladen, Assigned: Alexandru Savulov)



Windows XP

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt1], URL)


(3 attachments, 1 obsolete attachment)



16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7+)
Gecko/20020111 Netscape6/6.2.1+
BuildID:    2002032408

On ebay sales page, the seller has the option to add pictures using ebay's Ipix
image service.  The form allows you to browse to a location on your own computer
where the image is located, and the page uploads the image to their servers. 
This works in IE, NS4.x, and in netscape 6.1.  It also USED to work in mozilla,
but around milestone .97, it starts throwing up their "error 137" on the next
page, saying image upload has failed, and giving a list of possible reasons -
the most likely would seem to me to be an invalid image path - but I have tried
several different locations and images with the same failure.  

The Ipix service uses javascript on netscape, or activeX on IE.  I get the
following javascript error twice in the console each time I submit:

Error: redeclaration of const hide
Source File: chrome://wallet/content/walletOverlay.js 
Line: 1

I am aware that you must have an ebay account to test this.  I am hoping that
other bugzilla members with accounts could confirm this.
I am also attaching the source from IE's view of the page ( I couldn't get the
source in mozilla)  

I can reproduce this on both Windows XP and 98.

Reproducible: Always
Steps to Reproduce:
1.  go to www.ebay.com
2.  click on "sell" (must have an account)
3.  scroll to "picture services", and click "browse" next to "picture 1"
4.  select jpg or gif file on your computer (less than 50 k in size is        best)
5.  click "continue" button on bottom of page

Actual Results:  small window pops up to tell you image is being submitted, with
progress bar on bottom, then next page loads with "error 137"

Expected Results:  small popup should be followed by loading a page to allow you
to preview your auction, including the submitted image.

Comment 1

16 years ago
Created attachment 76169 [details]
Source code for the affected page saved in IE.

Comment 2

16 years ago
Created attachment 76170 [details]
Screenshot of error message from eBay

This is the error eBay returns.

Comment 3

16 years ago
likely dup of bug 132673. Any advanced use of WMP and Shockwave were also
broken. Fixed 03/26/2002 03:15.

Comment 4

16 years ago
Confirming, 2002032610, Windows 2000.  Exactly as reported described.
Ever confirmed: true

Comment 5

16 years ago
Not related to bug 132673.  This was a problem a while before that bug appeared,
and still continues with today's build (2002032708).  

Comment 6

16 years ago
This is a regression that occured between 02-12-2002 and 02-18-2002. Marc
Attinasi can confirm this, we tested with his account.

please see if this can be narrowed down to a day or lower so that we can find
the check in that caused the regression. I will work on this too. Thanx!
Severity: normal → critical
Keywords: nsbeta1, topembed
Priority: -- → P3
Target Milestone: --- → mozilla1.0

Comment 7

16 years ago
new time window for the regression:

2-16-2002 and 2-18-2002

Comment 8

16 years ago
we think it was caused by the patch for bug 120682
nsbeta1+, topembed+. [adt1]. Can not upload picture of for sale item on EBAY.
Severity: critical → major
Keywords: nsbeta1, topembed → nsbeta1+, topembed+
Priority: P3 → P1
Whiteboard: [adt1]

Comment 10

16 years ago
Created attachment 77576 [details] [diff] [review]
patch preview

this is what happened:

we stopped attachng the file name if there is no file or the name is invalid.

here are 2 snapshots of the raw HTTP trafic:

before fix for bug 120682:
Content-Disposition: form-data; name="file2"; filename=""
Content-Type: application/octet-stream

Content-Disposition: form-data; name="file3"; filename=""
Content-Type: application/octet-stream

after the fix:
Content-Disposition: form-data; name="file2"

Content-Disposition: form-data; name="file3"

now i think that we have to keep doing what we did before. i tested the ebay
page and it works.


please take a look at the patch and let me know what parts to remove and how do
you prefer to restructure the


method, the parts that are afected after the call

    rv = file->InitWithUnicodePath(value.get());

there are parts that might be removed. before i do anything further i need your
oppinion please.
Created attachment 77607 [details] [diff] [review]
Patch v1.1

OK, I just went through and added a few things, we may as well go all the way
and do what IE does, submit filename and Content-Type *always* for file inputs,
even if there is no file.  Some programs apparently expect this behavior and
die horribly if it's not there.  Sigh.

This patch also fixes bug 132069, which I will shortly dup to this bug.
Attachment #77576 - Attachment is obsolete: true
*** Bug 132069 has been marked as a duplicate of this bug. ***


16 years ago
Attachment #77607 - Flags: review+

Comment 13

16 years ago
Comment on attachment 77607 [details] [diff] [review]
Patch v1.1

r= alexsavulov

some how i agree with me :-)
BTW, I used that patch to upload the patch, and also tested the behavior when

(a) an empty filename;
(b) an invalidly formed filename (C:\\blah.txt is invalid on Linux for example)
(c) a valid filename that does not exist (/usr/local/blahblahblah.blah for example)

(a) sends filename="" and shows content-type=application/octet-stream, as does IE.
(b) sends filename="C:\\blah.txt" (in that case) and shows
application/octet-stream, as does IE.
(c) sends filename="blahblahblah.blah" because that what it would have sent if
the file did exist (for security reasons, don't tell the server the user's
directory), and application/octet-stream.

Comment 15

16 years ago
Comment on attachment 77607 [details] [diff] [review]
Patch v1.1

Attachment #77607 - Flags: superreview+

Comment 16

16 years ago
Comment on attachment 77607 [details] [diff] [review]
Patch v1.1

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #77607 - Flags: approval+

Comment 17

16 years ago
added adt100 after checking with kevin mccluskey
Keywords: adt1.0.0

Comment 18

16 years ago
Have we tested on all platforms, and other types of Form Submission on other
sites? If yes, and it looks great, adt1.0.0+ (on ADT's behalf) approval for
checkin into 1.0.
Keywords: adt1.0.0 → adt1.0.0+


16 years ago
Summary: eBay Ipix images do not upload properly → [PATCH]eBay Ipix images do not upload properly

Comment 19

16 years ago
tested on windows, linux, mac

patch in 
fixed on the 1.0 trunk


Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 20

16 years ago
*** Bug 136339 has been marked as a duplicate of this bug. ***

Comment 21

16 years ago
verifying on build 2002-04-10-03-trunk windows 98, no more error messages


16 years ago
Keywords: fixed1.0.0

Comment 22

16 years ago
*** Bug 131845 has been marked as a duplicate of this bug. ***

Comment 23

16 years ago
*** Bug 133774 has been marked as a duplicate of this bug. ***

Comment 24

16 years ago
Verifying on 07/17 branch on windows 98
Keywords: fixed1.0.0 → verified1.0.0
You need to log in before you can comment on or make changes to this bug.