Closed Bug 1119376 Opened 10 years ago Closed 9 years ago

Uploading to imagevenue.com never completes

Categories

(Core :: General, defect)

34 Branch
x86_64
Windows 8.1
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: rick3162, Unassigned)

Details

(Keywords: flashplayer)

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 Build ID: 20141126041045 Steps to reproduce: In a clean Firefox profile: - open http://imagevenue.com/ - click "Browse", select an image file, select 'Image content type' and press "Send file(s)". Actual results: The uploading never finishes: the spinning wheel in the tab never stops, and the status bar keeps showing "Waiting for imagevenue.com....". The same happens with the latest Beta 35, Dev and Nightly editions. Expected results: The uploading should complete (it always completes in IE 11 and Chrome 39).
Component: Untriaged → General
Also, because the upload part of the page uses flash, the installed Shockwave flash version is the latest, 16.0.0.235.
Component: General → Untriaged
Keywords: flashplayer
Product: Firefox → Core
I guess it was the flash plugin causing this. With the latest flash v16.0.0.235 uploading completes ok, in stable 35 and Nightly 38 editions (that I tested). So, I'm closing this.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Sorry, I meant: > With the latest flash v16.0.0.257
I'm reopening this, because I tried many times these two days, in all Firefox versions, and uploading (almost) never completes. On the other hand, in IE and Chrome, during the same time, it always completes.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
(In reply to Kostas from comment #4) > I'm reopening this, because I tried many times these two days, in all > Firefox versions, > and uploading (almost) never completes. > On the other hand, in IE and Chrome, during the same time, it always > completes. Both of these, on Win8 at least, use their own copy of flash, unfortunately... Do you see any correlation at all with what image size you're uploading?
No, I think that there's no correlation. All the attempts I made, were with small sized JPEG images (<=150 KB). What's strange, is that, whenever I try with any Firefox version, the uploading stays at "Waiting for imagevenue.com...." indefinitely, but, during that time, if I try in IE or Chrome to upload the same image file the uploading always completes (and it's done quickly, within a few seconds).
(In reply to Kostas from comment #6) > No, I think that there's no correlation. > All the attempts I made, were with small sized JPEG images (<=150 KB). > > What's strange, is that, > whenever I try with any Firefox version, the uploading stays at "Waiting for > imagevenue.com...." indefinitely, > but, during that time, if I try in IE or Chrome to upload the same image file > the uploading always completes (and it's done quickly, within a few seconds). Any errors in the console when it gets stuck indefinitely? Have you tried in safe mode ( Help > Restart with add-ons disabled) ?
Flags: needinfo?(rick3162)
(In reply to :Gijs Kruitbosch from comment #7) > (In reply to Kostas from comment #6) > > No, I think that there's no correlation. > > All the attempts I made, were with small sized JPEG images (<=150 KB). > > > > What's strange, is that, > > whenever I try with any Firefox version, the uploading stays at "Waiting for > > imagevenue.com...." indefinitely, > > but, during that time, if I try in IE or Chrome to upload the same image file > > the uploading always completes (and it's done quickly, within a few seconds). > > Any errors in the console when it gets stuck indefinitely? Have you tried in > safe mode ( Help > Restart with add-ons disabled) ? No, there's no error in the console (what it shows is a JS Warning "Use of attributes' nodeValue attribute is deprecated. Use value instead" which is irrelevant. I just tried in safe mode, and the problem also exists. Also, just want to note, that the profiles for the Beta, Dev and Nightly versions that I use, are all clean.
Flags: needinfo?(rick3162)
Hi guys, Tested this on latest release (43.0.2) and does not reproduce, however on latest nightly build (46.0a1 - 20160104030217) when clicking the browse button the Filepicker window does not open. I've tried to find the regression range using mozregression tool and found out that the changes made in Bug 1185532 affected this functionality. I'm updating the issue component for a better visibility. Bob, can you please look into this issue and provide more information? Thank you, Vlad
Component: Untriaged → XUL
Flags: needinfo?(bobowen.code)
(In reply to Vlad Bacia from comment #9) > Hi guys, > > Tested this on latest release (43.0.2) and does not reproduce, however on > latest nightly build (46.0a1 - 20160104030217) when clicking the browse > button the Filepicker window does not open. > I've tried to find the regression range using mozregression tool and found > out that the changes made in Bug 1185532 affected this functionality. > I'm updating the issue component for a better visibility. > > Bob, can you please look into this issue and provide more information? > > Thank you, > Vlad I think you must be running the 64-bit version of Nightly, so this this sounds like a different bug to the original one. Please would you try testing again with environment variable MOZ_DISABLE_NPAPI_SANDBOX=1 set before starting Nightly. If that fixes it please file a new bug blocking bug 1185532.
Flags: needinfo?(bobowen.code)
Flags: needinfo?(vlad.bacia)
Depends on: 1236911
I have tested on the x86 browser version and also on x64 browser version with variable "MOZ_DISABLE_NPAPI_SANDBOX=1" set, and indeed the issue cannot be reproduced. Considering this, I have logged a new issue - 1236911, as requested. Thank you, Vlad
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(vlad.bacia)
Thanks Vlad, I'll look into bug 1236911. Just resetting this back to the previous states as it appears we still can't reproduce. Kostas - are you still able to reproduce this?
Status: NEW → UNCONFIRMED
Component: XUL → Untriaged
No longer depends on: 1236911
Ever confirmed: false
Flags: needinfo?(rick3162)
I tested it quite a few times (43.0.3 x86, fresh profile) and it didn't occur. So, I'm closing it. Thanks for the replies
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago9 years ago
Flags: needinfo?(rick3162)
Resolution: --- → WORKSFORME
Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598
Component: Untriaged → General
You need to log in before you can comment on or make changes to this bug.