Closed Bug 616902 Opened 15 years ago Closed 14 years ago

File upload by drag & drop causes navigation away from page on yandex.ru

Categories

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
blocking2.0 --- -

People

(Reporter: i3v, Unassigned)

References

()

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 Drag&drop box on a file-sharing service http://narod.yandex.ru/ is not working on FF4b7 (first part of video) while working OK on FF3.6.12 (second part of video). Instead of file uploading, it prompts you if you want to close the page. After selecting 'no' uploading is freazed at 0%. Reproducible: Always Steps to Reproduce: 1. goto http://narod.yandex.ru/ 2. try to drop any file to those box.. Actual Results: Instead of file uploading, it prompts you if you want to close the page. After selecting 'no' uploading is freazed at 0%. Expected Results: File being uploaded, as ff3.6 , as 2nd part of video. http://www.youtube.com/watch?v=xevM9p2uNLY
Hardware: x86_64 → x86
In order to test the site, an account is needed. I create a dummy account which others are welcome to use to test this issue (u: ed-ed-test2010 p: this bug ID pasted twice). STR: (For those that can't read Russian) 1) Visit http://narod.yandex.ru/ 2) Click the green text top right of the page and enter username and password to login. 3) Drag and drop a file to the white box with an arrow. Expected: - File uploads and appears listed below the arrow box. Actual: - Confirm message: "This page is asking you to confirm that you want to leave - data you have entered may not be saved." shown. - Upload stuck at 0%. - ie: As per the video in comment 0. Works fine with Firefox 3.6.13 and Chrome 10.0.612.3 dev.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
Clarification for step #2 in comment 1: After entering the username and password, the "ok/login" button is the one on the left. Confirmed using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20101231 Firefox/4.0b9pre ID:20101231030358 Last good nightly: 2010-04-19 First bad nightly: 2010-04-20 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=85c3175de68f&tochange=5f229488969c To eliminate this being a useragent sniffing problem, the user agents for the good and then the bad builds are respectively: - Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100419 Minefield/3.7a5pre - Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100420 Minefield/3.7a5pre ...so no major differences/not related.
blocking2.0: --- → ?
Component: General → Drag and Drop
Keywords: regression
Product: Firefox → Core
QA Contact: general → drag-drop
Summary: file drag&drop not working → File upload by drag & drop causes navigation away from page on yandex.ru
Keywords: testcase-wanted
Bug 560166, which is drag-and-drop related, landed in that range. Neil, can you take a look?
Blocks: 560166
The page is responding to the drop event but not canceling it, so the default behaviour of loading the dragged file occurs. The alert appears as the page seems to be canceling the unload event.
Blocks: 545714
No longer blocks: 560166
If we are going to promote drag and drop as a new feature, it sounds like this needs to block right? Who is the right owner to do the patch?
I wonder whether bug 595789 comment 10 is the same issue reported on Linux. There, the expectation was that stopPropagation() would also cancel the default action.
Marking this blocking minus as so far this seems like a website bug, based on comment 4. So maybe we should move this over to evangelism. Kev: Do you have contacts at yandex which we could contact regarding this. Neil should be able to help out with telling them how they need to change their site to get this working.
blocking2.0: ? → -
Is tech evang still a viable conclusion, given comment 2, seeing as it used to work before a Fx change and now doesn't? (and user agent sniffing doesn't appear to be the problem either)
As far as I know, this bug was fixed. I can't reproduce it now.
Yep, all is working as it should on my FF5.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.