Problems uploading to facebook
Hi I just wanted to let you know I'm having a problem with uploading photos or videos to facebook with the most recent release. The problem dose not exist when using facebook in Safari or on my windows pc using firefox or chrome.
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Cameron Kaiser on 13 Nov, 2015 12:36 AM
Can you be more specific?
2 Posted by Brian Szemon on 13 Nov, 2015 01:06 AM
when I goto click the file (e.g. Photo or Video) the animation comes up but sits their and never uploads. As I said safari 4.1.3 works great. It's something to do with the browser or communication between facebook and the browser not sure. I'll attach a photo below.
3 Posted by Brian Szemon on 13 Nov, 2015 01:11 AM
On another note the only type of file I can upload successfully is a .png photo image .jpg will not upload.
Support Staff 4 Posted by Chris (chtrusch... on 13 Nov, 2015 05:37 AM
I see this, too, but it's also in 38.3. Started this week and I suspect it's a change Facebook introduced. I reported the problem to FB yesterday. Also, I'll do more tests with Firefox 38 ESR/Windows.
Support Staff 5 Posted by Chris (chtrusch... on 13 Nov, 2015 12:24 PM
OK, let's see:
TFF 17: Works without problems for uploading jpgs.
TFF 38.3/38.2.1: Uploading jpgs doesn't work. It used to work until (at least) Oct. 22, that's when I last uploaded pictures to FB with TFF 38.x. Spoofing a FF useragent doesn't work, either.
FF 38.4 Win: uploading .jpg results in an error message overlay, however the image is uploaded. A test of Mac-FF 38.4 is necessary.
TFF 38.4: Uploading jpgs doesn't work. Uploading pngs does work. Renaming a jpg to png (or tif) and then uploading it also works. Facebook just doesn't like the jpg suffix, there is no technical reason and nothing actually broken on our side, I think. Maybe some upload filter/security mechanism? Until this is sorted out by FB, just rename pictures to .png (it doesn't matter, FB recompresses them anyway).
Support Staff 6 Posted by Cameron Kaiser on 13 Nov, 2015 03:03 PM
Chris, is there anything in the console of note (Brian: you can check yourself by going to Tools > Web Developer > any of Web Console, Network or Browser Console -- don't post the whole thing, please, just anything that appears there at the moment you try to upload an image)?
7 Posted by Brian Szemon on 13 Nov, 2015 04:44 PM
Web Console:
TypeError: asm.js type error: AsmJS not currently supported on PowerPC
"Assertion failed: Typed arrays 2 must be run on a little-endian system"
"Assertion failed: Typed arrays 2 must be run on a little-endian system"
Use of getAttributeNode() is deprecated. Use getAttribute() instead.
Network:
https://3-edge-chat.facebook.com/pull?channel
Type: json
over 50000ms
this seems to be the problem as it repeats in the network console over and over.
~Photo is attached
Support Staff 8 Posted by Chris (chtrusch... on 13 Nov, 2015 06:18 PM
I get the same console messages about PPC and little endian, but I get them all over the place: when loading my profile page (most of the time), on the messages page, sometimes when loading the Timeline. They don't seem to be related to uploading files. I do get these also when uploading a file for the first time, more precisely when the dialog opens that lets you choose the file from your computer. At this stage, FB doesn't yet know that I want to upload a jpg. Uploading itself (after selecting the file) doesn't give me any additional console message at all, no matter if it's jpg or png.
I get these longer timings in Network (1500-5000 ms) for https://xxx-edge-chat.facebook.com even if I don't try to upload anything. They seem to be related to the chat.
BTW Facebook has a cool console message right after loading pages, see picture attached.
9 Posted by Brian Szemon on 13 Nov, 2015 06:31 PM
I use my G4 7450 Mac Mini everyday Went as far as upgrading the ram to 1GB myself just because apple and others say my mac is obsolete I don't think so, Eventually I will have to upgrade to an Intel mac that though is disturbing lol. As far as TenFour Fox goes have had minor hickups but nothing as big as this.
10 Posted by Juergen on 15 Nov, 2015 03:05 PM
Same here. The problem with Facebook came up first at 11th of november 2015. It happens (to me) in only one situation: When trying to add an additional image to a link-posting. After choosing the image, nothing happens: no upload - but instead the console is fireing up some messages about "asm.js is not supported on powerpc". All other cases of uploading images and videos are working fine - and asm.js is not even mentioned in the console.
I reported the problem to Facebook. But I got no reaction, because I really didn't know what the exact reason of the problem is.
Thanks a lot to Chris: Changing the image suffix from JPG to PNG fixes it.
TenFourFox 38.4.0, Mac OSX 10.4.11, 1.5 GHz PowerPC G4, Mac Mini
Support Staff 11 Posted by Cameron Kaiser on 15 Nov, 2015 09:31 PM
The 50000ms timeout isn't the problem, that's Facebook Chat.
The asm.js issue could be the problem, but if it is, there's no solution. The JavaScript engine is altered so that asm.js simply falls back on the regular JIT (with a warning, as you see). The reason I wrote it that way is because virtually all of the asm.js out there assumes a little endian byte order, and Power Macs are big endian, so there was no point in trying to optimize something that won't run correctly on our systems in the first place. In fact, the assertions it throws indicate that Facebook's code is doing exactly that. There is no way around this because there's currently no way to know the inherent endianness of the asm.js code it's trying to run.
Facebook should have a fallback here, but my suspicion is that they see Firefox, and mistakenly assume it's Firefox on x86 or little-endian ARM. If you change the user agent to Safari, which does not have asm.js support, does it act differently?
Support Staff 12 Posted by Chris (chtrusch... on 16 Nov, 2015 11:51 AM
This doesn't make a difference (Safari 6 on Mac OS X 10.7).
Chris (chtrusch) closed this discussion on 16 Nov, 2015 11:51 AM.
Chris (chtrusch) re-opened this discussion on 16 Nov, 2015 11:51 AM
Support Staff 13 Posted by Cameron Kaiser on 16 Nov, 2015 02:45 PM
Then we need three more data points:
If there is a difference between the first two, then it's a change between 38 and current I need to investigate.
If the first two work but the third doesn't, it's probably the endianness issue.
If they all work, then it's a local bug I introduced somewhere (possibly another JIT edge case).
Support Staff 14 Posted by Cameron Kaiser on 16 Nov, 2015 02:49 PM
Actually, before all that: if you disable the JIT (turn off baseline, turn off ion, turn off native regexp), does it work? Any combination that it does work? (Baseline on, Ion off, ... ?)
Support Staff 15 Posted by Chris (chtrusch... on 16 Nov, 2015 03:33 PM
Still doesn't upload with the JIT disabled completely or in combinations.
I won't have the chance to get my hands on an Intel Mac (at least not one I can install software on) until the next weekend.
16 Posted by Brian Szemon on 16 Nov, 2015 06:19 PM
Thanks for trying to work out the bug or kink in whatever is going on. I have been gone my job takes me all around wish I could help further the effort but this is the only machine I have hope something sheds light on this.
17 Posted by Brian Szemon on 20 Nov, 2015 11:42 AM
I have still not found anything and have reported the problem detailed to facebook with out much response. Wonder if a script could be written to automatically change .jpg to .png to spoof the system with out user involvement?
18 Posted by Brian Szemon on 20 Nov, 2015 03:39 PM
Until this can be solved if it even can be, I still think it's on facebooks end I just found out how to export photos from iPhoto to .png and things are working that way. Thank you both for trying to solve this.
19 Posted by Juergen on 22 Nov, 2015 05:29 PM
---
Cameron asked: If you change the user agent to Safari, which does not have asm.js support, does it act differently?
---
The latest native PPC Safari version 4.1.3 doesn't have the reported problem: JPG-upload to Facebook linkposts works fine.
This version is not listed by default in the user agent list of TenFourFox. Someone with more knowledge than me in editing user agent profiles should test it.
However: Like Chris mentioned - changing the image suffix in the finder before the upload from JPG to PNG fixes it. Upload works fine. Facebook doesn't care, if the image is in fact a JPG.
Support Staff 20 Posted by Cameron Kaiser on 22 Nov, 2015 10:58 PM
That's not what I asked. If changing the user agent fixes it, then we know Facebook is sniffing the user agent and sending code we're not compatible with.
Since the JIT does not appear to be to blame, we now need a data point from someone on PPC Linux Firefox to know if it's an endian issue.
21 Posted by bobbymacbean on 28 Nov, 2015 10:23 PM
This has been frustrating me for a few weeks. Converting / changing file type to .png is a quick and simple fix. Just to be on the safe side, I opened each of the pics I wanted to upload and saved as a separate file using .png so I would not lose the .jpg files. Thanks for the tip Brian Szemon & Chris (chtrusch). (; >
22 Posted by Tobias Netzel on 26 Dec, 2015 10:57 AM
This is most probably an endian issue indeed, because the same thing does also happen when trying to upload to facebook using leopard-webkit on PPC machines.
@Cameron Kaiser:
I think the only solution would be to emulate little endian typed arrays. In WebKit I had already done this once but reverted it because it broke WebGL (or would at least slow it down because of at least one byte order conversion on the way to the GPU). Maybe I'll have to rethink that decision and discard fast WebGL in favour of emulating little endian typed arrays - after all WebGL is not that important.
My investigations regarding this problem revealed that in order to circumvent endian issues one simply has to interpret "little endian" as "native endian" and "big endian" as "non-native endian" - and in fact that seems to be the way single endian programmers understand "little" and "big endian".
In leopard-webkit I implemented this change for accessing an ArrayBuffer using DataView; the second (optional) argument to DataView's setters and getters is interpreted as "native endian" (specification says "little endian"), defaulting to "non-native endian" (specification says "big endian"). That change, while potentially not providing best speed because of defaulting to "non-native" instead of "big" endian, makes DataView API independent from CPU endianness - provided the ArrayBuffer is accessed through DataView exclusively. That way most (if not all) endianness issues in test suites were fixed successfully - after all knowing the exact endianness does only really matter when data needs to be interchanged between different cores (like different types of CPUs and/or GPUs) using all sort of interfaces (like PCI, UART, Ethernet, ...); when dealing with data on one CPU only (or a single virtual machine, like a JavaScript engine) native or non-native byte order should be all you need to know (or be able to specify) in almost any case.
Support Staff 23 Posted by Cameron Kaiser on 26 Dec, 2015 11:31 PM
That seems logical. I'll probably need to make analogous changes to both the JIT and interpreter. I'm not sure I'd like to do this as a running change with 38.
24 Posted by Tobias Netzel on 31 Dec, 2015 04:17 PM
I can confirm that facebook upload does work properly in leopard-webkit after changing TypedArrayViews to always read and write values in little endian byte order. There's no need to change the byte order of the ArrayBuffer itself. I guess facebook uses the typed arrays to parse EXIF data (like GPS coordinates).
As a consequence I removed my changes to DataView; having endianness swapped in both DataView and TypedArrayViews leads to confusion (like endianness tests detecting the byte order as big endian again).
Of course the change broke WebGL - might not be easy to fix that in WebKit, but that's no problem for TFF.
Depending on the implementation changing the endianness of TypedArrayViews might affect a number of APIs like WebGL, Canvas, FileReader, WebSockets, WebRTC, Web Workers and Web Audio - JavaScript typed arrays seem to become more and more important.
Support Staff 25 Posted by Chris (chtrusch... on 01 Mar, 2016 10:43 AM
This problem has now been fixed by Facebook.
26 Posted by tobias.netzel on 05 Mar, 2016 11:25 PM
Working again in leopard-webkit, too - without TypedArrayViews reading/writing little endian data. (That was my only test case for testing TypedArrayView's endianness...)
Support Staff 27 Posted by Cameron Kaiser on 06 Mar, 2016 03:50 AM
There was still some issues with the ChaCha polyfill for WhatsApp, so that might be the next place to try.
I'll leave this open for the moment, though.
28 Posted by Brian Szemon on 22 Mar, 2016 04:35 PM
It's working again I'm uploading .jpg to facebook no more needing to convert to .png thank you for the fix and I'm happy I could help out a bit with this after all tenfourfox saved my ppc mac from just being shelved or turned into a server. Thank You very much :)
Support Staff 29 Posted by Cameron Kaiser on 13 Nov, 2016 03:14 AM
Just as a followup, if Facebook uses the original code again, it has been repaired in 45.5.0 which is now available as a release candidate on http://tenfourfox.blogspot.com/ . Therefore, I'm going to close this ticket. If there are future problems related to uploading images to Facebook, please open a new ticket instead of using this one.
Cameron Kaiser closed this discussion on 13 Nov, 2016 03:14 AM.