Closed
Bug 1119376
Opened 10 years ago
Closed 9 years ago
Uploading to imagevenue.com never completes
Categories
(Core :: General, defect)
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).
Also, because the upload part of the page uses flash,
the installed Shockwave flash version is the latest, 16.0.0.235.
Updated•10 years ago
|
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
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 → ---
Comment 5•10 years ago
|
||
(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).
Comment 7•10 years ago
|
||
(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)
Comment 9•9 years ago
|
||
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)
Comment 10•9 years ago
|
||
(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)
Updated•9 years ago
|
Flags: needinfo?(vlad.bacia)
Comment 11•9 years ago
|
||
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)
Comment 12•9 years ago
|
||
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)
Reporter | ||
Comment 13•9 years ago
|
||
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 ago → 9 years ago
Flags: needinfo?(rick3162)
Resolution: --- → WORKSFORME
Comment 14•8 years ago
|
||
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.
Description
•