Closed Bug 133453 Opened 22 years ago Closed 22 years ago

[PATCH]eBay Ipix images do not upload properly

Categories

(Core :: DOM: Core & HTML, defect, P1)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: lgladen, Assigned: alexsavulov)

References

(
URL
)

Details

(Keywords: topembed+, Whiteboard: [adt1])

Attachments

(3 files, 1 obsolete file)

Source code for the affected page saved in IE.
110.16 KB, text/plain
Details
Screenshot of error message from eBay
17.92 KB, image/gif
Details
Patch v1.1
2.68 KB, patch
alexsavulov
: review+
attinasi
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
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.
This is the error eBay returns.
likely dup of bug 132673. Any advanced use of WMP and Shockwave were also
broken. Fixed 03/26/2002 03:15.
Confirming, 2002032610, Windows 2000.  Exactly as reported described.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Not related to bug 132673.  This was a problem a while before that bug appeared,
and still continues with today's build (2002032708).  
This is a regression that occured between 02-12-2002 and 02-18-2002. Marc
Attinasi can confirm this, we tested with his account.

Vladimire:
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
new time window for the regression:

2-16-2002 and 2-18-2002
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]
Attached patch patch preview (obsolete) — — Splinter Review 
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:
...
-----------------------------157241916926500
Content-Disposition: form-data; name="file2"; filename=""
Content-Type: application/octet-stream


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

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


-----------------------------265001916915724
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.

John:

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

 nsHTMLInputElement::SubmitNamesValues 

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.
Attached patch Patch v1.1 — — Splinter Review 
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. ***
Attachment #77607 - Flags: review+
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
entering:

(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 on attachment 77607 [details] [diff] [review]
Patch v1.1

sr=attinasi
Attachment #77607 - Flags: superreview+
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+
added adt100 after checking with kevin mccluskey
Keywords: adt1.0.0
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+
Summary: eBay Ipix images do not upload properly → [PATCH]eBay Ipix images do not upload properly
tested on windows, linux, mac

patch in 
fixed on the 1.0 trunk

WHASUP eBAY DUDES... BE COOL... USE OUR BROWSER! ;-)
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 136339 has been marked as a duplicate of this bug. ***
verifying on build 2002-04-10-03-trunk windows 98, no more error messages
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.0
*** Bug 131845 has been marked as a duplicate of this bug. ***
*** Bug 133774 has been marked as a duplicate of this bug. ***
Verifying on 07/17 branch on windows 98
Keywords: fixed1.0.0 → verified1.0.0
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: