scudcloud
scudcloud copied to clipboard
raelgc
Hangs on Opening / Stuck at Motivational Quotes
ScudCloud Version
ScudCloud 1.57 Python 3.5.2 Qt 5.5.1 PyQt 5.5.1 SIP 4.17
Distro and Desktop info
Ubuntu 16.04 64-bit Unity desktop Kernel version: 4.4.0-92
Expected behavior
Actual behavior
When launched, Scudcloud hangs with the loading animation, but never loads any data. Cannot find anything relevant in logs: syslog, Xorg.0.log, etc. Not sure where Scudcloud logs activity.
Often, closing the window and restarting Scudcloud a few times fixes it. Today, restarted Scudcloud at least 10 times. Finally everything loaded after trying Edit/reload about 4 times.
Screenshot attached.
The "self help test" succeeds; results pasted below:
IP Address: 128.xxxxxxxxx
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
JavaScript: Enabled
jQuery Loaded: Success
Asset CDN: Success (594ms)
Files Legacy: Success (767ms)
Files Edge: Success (395ms)
Files Location: Success (Slack files US West (Oregon) (location: A backend: imgproxy-04a2ca72f3a69c4e1))
Web Socket (Message Proxy A): Success
Web Socket (Message Proxy B): Success
Web Socket (Message Proxy C): Success
Web Socket (Message Proxy D): Success
Web Socket (Flannel): Success
Web Socket (Flannel [No Compression]): Success
Bandwidth: Success (167.3 Mbps, 67 ms ping)
Everything seems to have worked. If you're still experiencing problems, tell us about it.
Steps to reproduce
- Launch Scudcloud, either from the command line ("scudcloud &") or from the dock icon.
Hi @pfogel and thanks for reporting this issue.
I didn't notice this... are you under a slow or intermittent connection?
Anyway, I'll keep an eye on my desktop too to check if I'll watch this behavior.
My connection is fast and steady; part of a University infrastructure and in a building that used to house a super computer center: >200 Mbps.
I reported this because it has been happening pretty consistently. Every morning when I launch Scudcloud I have to restart it multiple times. This morning it took more than 30 minutes of fussing with it to get it to load data.
Where does it log so that I can check what is going on? Or do I need to launch it in debug mode or something like that?
You can check the JS console: start in the command line with scudcloud --debug=True &, then after it loads, right click in the message pane and select Inspect.
Maximize the Inspector window and click in the Console tab.
I'm seeing the same issue on Archlinux (amd64 kernel 4.12.3): Scudcloud 1.61, python 3.6.2, pyqt5 5.9.
When launched with debug, I can see some errors in the console, I've attached them in this gist: https://gist.github.com/mtb-xt/d4efe788cd4200fde0014ab0dfe983c7
I'm on 200 mbit\s symmetrical connection, and yes, restarting several times fixes the issue. But it started only a few days ago for me.
Seeing the same issue. The error are the same as reported by mtb-xt. Btw I have 2 teams added.
@mtb-xt I can see several Slack JS errors. Other platform users complained about them too: https://bugs.webkit.org/show_bug.cgi?id=149551
I have a different webkit version running here (I've installed KDE Neon PPA). I'll open the debug console and check if I can see the same JS errors.
ScudCloud 1.50 Python 3.5.3 Qt 5.7.1 PyQt 5.7 SIP 4.18.1
for me it also started a couple of days ago, so I don't think the webkit issue has anything to do with this. Also - sometimes scudcloud is able to properly load, if I load slack and login in the browser.
performance much better the last 2 days, but i'm not aware of any changes on my end. opens on the first try and loads reasonably quickly. possible something changed at slack?
ScudCloud itself has not changed in the last 2 months. All Slack changes. They keep working and improving their JS. Sometimes they introduce a change that breaks our simple client and we need to change. But sometimes are just changes that they see are breaking some platforms, so they revert or fix.
I wish they had a proper API, but probably this will never happen.
I also get this on Arch, but only on the second of two teams. It doesn't matter if I restart, refresh, or sign out and back in. That second team never loads.
ScudCloud 1.61 Python 3.6.2 Qt 5.9.1 PyQt 5.9 SIP 4.19.3
Someone still affected by this issue? Today I just pushed a webkit update for those on Ubuntu xenial and zesty.
I've seen this yesterday and today. Exiting and starting scudcloud again got it working.
@skarap, still an issue for you? There are 2 issues related to this:
-
#546: when connection is lost for some minutes, Qt network libraries in qt5 didn't properly recognize when the connection is available again
-
#271: if program starts without internet connection, and the connection is restored after the loadURL timeout, it'll not start properly.
Haven't seen it for a few days now. Will send an update if it stops working again. Thanks
Today, it started happening again to me too. I'm running Arch Linux.
$ scudcloud --version
ScudCloud 1.63
Python 3.6.2
Qt 5.9.1
WebKit 602.1
PyQt 5.9
SIP 4.19.3
Same here. Turned off Scudcloud the last night, unable to start it since this AM :(
Doing the JS debug console thing, I see a load of errors at the bottom. Trying to upload a screenshot but I get an error from github :(
I just tested here in a VM with KDE Neon (i.e., an environment with a newest qt+webkit) and it worked fine.
Yup, was working fine previously, but now I just get an infinite spinny. Arch Linux, installed from the AUR.
ScudCloud 1.63
Python 3.6.2
Qt 5.9.1
WebKit 602.1
PyQt 5.9
SIP 4.19.3
Same as previously posted on Arch. I'm also trying to load the second team I added.
Thanks for your work, BTW, I appreciate it. Very useful.
Yep, I'm back to this also.
ScudCloud 1.57 Python 3.5.2 Qt 5.5.1 PyQt 5.5.1 SIP 4.17
And I also agree with RealGrep: very highly appreciate your hard work. Many thanks.
Am going to try installing the most recent release. (Have been using the version in the repo.) OK, that didn't do anything. Same behavior. Not fixed by repeatedly selecting "Reload" from the Edit menu.
A colleague has informed me that there is now an official Ubuntu and Fedora package for Slack: https://slack.com/downloads/linux . Last time I checked they didn't have any.
Again, thanks to Rael for all of his hard work here.
I'm trying to find a workaround for this (spent almost my entire morning on this). But the problem is: even the updated webkit I've published last month is not new enough to get the latest Slack working.
I tried in a KDE Neon (16.04) machine and it worked, but the packages to update are too many.
@pfogel Yes, there is an official client and it's really good.
Got same issue with last version ( #600 )
ScudCloud 1.63 Python 3.5.2 Qt 5.5.1 WebKit 602.1 PyQt 5.5.1 SIP 4.17
Distro and Desktop info : 4.10.0-33-generic // 16.04.1-Ubuntu // x86_64 GNU/Linux
Merci
@skelband I 2nd your thoughts -- @raelgc really appreciate your efforts here.
bums me out a bit. the "official" slack client does not support the X11 URGENCY bit in WM_HINTS, which I helped add to scudcloud.... sure is nice to be able to take things apart and put them back together how you want.
again @raelgc appreciate your efforts.
Same issue here. My profile matches that of ghostofkendo and RealGrep above. I'm on Manjaro, have built (and rebuilt) from AUR, have stable bandwidth, use ~5 Slacks within, and also tried a fresh .cfg to rule out something sideways in my profile. @raelgc I'm grateful for your effort here. Scudcloud is a pleasure to use.
$ scudcloud --version
ScudCloud 1.63
Python 3.6.2
Qt 5.9.1
WebKit 602.1
PyQt 5.9
SIP 4.19.3
Same issue here.
It occurred recently just after dist-upgrading the Ubuntu.
~$ scudcloud --version
ScudCloud 1.63
Python 3.5.2
Qt 5.5.1
WebKit 602.1
PyQt 5.5.1
SIP 4.17
~$ uname -a
Linux Alexa 4.4.0-93-generic #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
Console log:
TypeError: d["a"].File is not a function. (In 'd["a"].File()', 'd["a"].File' is an instance of ProxyObject)
TypeError: undefined is not an object (evaluating 'TS.interop.redux.configureStore')
TypeError: undefined is not an object (evaluating 'a.id')
Guys I'm sure he gets it by now. Just thumbs-up this or an earlier comment if you have the same issue, and if you want notifications click the subscribe button. <3
Same issue for me on Fedora 26
scudcloud-1.60-1.fc26.noarch python2-2.7.13-12.fc26.x86_64 python3-3.6.2-5.fc26.x86_64 qt-4.8.7-28.fc26.x86_64 package pyqt is not installed sip-4.19.1-1.fc26.x86_64
Same issue here on Fedora 26:
ScudCloud 1.63 Python 3.6.2 Qt 5.7.1 WebKit 602.1 PyQt 5.8.1 SIP 4.19.1
Guys, I spent a good time checking this. It's an "issue" in the Slack JS, very deep one (several layers of obscurity). I wrote "issue", because it works in updated web engines, but not in the qt version Ubuntu 16.04 and Fedora are using.
Solution one could be try to de-obfuscate their JS and see the whole reason for the failure.
Another solution would be upgrade again the web engine, but this time the upgrade would be huge.
The third alternative solution is to use the Qt WebEngine (which is based in Chromium), but will rely on upgrade a bulk of libraries too.
How do these options compare to each other?
What kind of "huge" are we talking about if the web engine gets upgraded?
The first solution doesn't seem feasible unless you have a lot of free time on your hands, and know what you're doing I think.
@raelgc Thank you for quick reply, I really appreciate your work.
Can you include versions of web engine that works?
Do you consider using eg. flatpak for creating budle of scudcloud with up-to-date web engine included, so there will be no dependency hell for users?
Is there any way how can I help you? (Altough I don't have any JS knowledge, but maybe with flatpak etc.)
@Alveel and @HalisCz, good questions.
Let me try to answer and give more solutions. I'd love comments!
1. Update webkit again
To upgrade webkit again, we need to upgrade more libraries this time (we're already using the most updated supported in 16.04 using default libraries). My first thought was trying to check the packages and dependencies in KDE Neon, because it's 16.04 and it has an updated webkit. But afraid it can break stuff. This will be smallest solution size, I think at least around 500MB.
To investigate this, we should get a KDE Neon install (I have it in a VM) and investigate all webkit dependencies (the package name is libqt5webkit5). I started to investigate once, but didn't finish (several dependencies), maybe there is an easier way to check Debian package dependency tree.
2. Use Qt WebEngine (Chromium based)
To use Qt WebEngine, I know the library is missing in any Debian based distros, but we should be able to download and build it from Qt website. But this uses around 1GB (last time I checked).
And it'll require some update in our code too: http://doc.qt.io/archives/qt-5.5/qtwebenginewidgets-qtwebkitportingguide.html
3. Flatpak
@HalisCz I thought about a flatpak/snap too. But last time I checked the snap dependencies, they were huge too (around 3GB). I'll check if flatpak has less dependencies for webkit/webengine.
4. Try a Electron/JS solution
That will be similar to the official app... what makes me wonder:
5. What's the point of ScudCloud today?
We're playing cat/mouse game here always trying to accommodate all Slack HTML/CSS/JS changes when they break ScudCloud. Made sense when no official client was provided, but now I got wondering if spend so much time with this (usually at night when family is sleeping) makes sense.
It's not Slack fault: they're a company and supposing to keep moving forward. They have an official client since some time ago, and they even improved the memory usage. Of course, we can discuss if they should offer a real API or not, but this is their business.
@raelgc
- Update webkit again
I would suggest run clean docker container with distribution of choice (ubuntu 17.04 I guess) and try to install requested version of webkit. Apt will ask if you agree to install all those dependencies and it wil list them.
- Use Qt WebEngine (Chromium based)
I am not sure about the idea of trying to fit in weekly updated scudcloud into rock-solid stable distribution like debian. Either users want updated scudcloud, so they should get updated webkit (so no reason to use Qt WebEngine), or they are not. If you are seriously thinking about bundling libraries within scudcloud package, I would deeply suggest flatpak (because of this is it's purpose)
- Flatpak
I would be happy to help you develop flatpak package, altough I've never tried (yet). If you have library issues, I think this is the correct way.
- Try a Electron/JS solution
Agreed. I dislike this option.
- What's the point of ScudCloud today?
Only the project owner can settle the project's purpose. But I can say that I am using scudcloud because:
- I can keep it running in tray and separated from other apps, so when there is pop-up notification, I don't have to browse through 400 tabs in 10 browser windows
- It is not Electron/JS-it-will-eat-all-your-ram piece of sh*t
Unless I have missed it the official client for Linux doesn't work with proxy servers. That is the main reason I had stuck with scudcloud even after they launched the official client.
Unless I have missed it the official client for Linux doesn't work with proxy servers.
@djb61 From https://get.slack.help/hc/en-us/articles/212924728-Slack-for-Linux-beta-
You can specify the proxy server used with the
--proxy-server=IP:portcommand line switch
- Update webkit again
I would prefer this.
- Use Qt WebEngine (Chromium based)
Might be doable as well.
- Flatpak
That's just not good for distributions where I want to have native packages.
- Try a Electron/JS solution
Please, don't.
- What's the point of ScudCloud today?
It's an application which is packaged and I can use it for slack ;)
It's a long shot, but is there any mileage in talking to Slack? Perhaps it would be no big deal for them to modify their code for compatibility. They could tell you to bog off but it might be worth the effort. Whatever they changed that broke Scudcloud can't be that profound. Using their official client in the interim and it just looks the same as it always did.
For my $.02 - I generally prefer free, open source tools to proprietary ones. For example, even though we are now using Slack, we offload many of the integrations to hubot. I appreciate how light and functional scudcloud has been for me until now on Fedora.
As far as packaging, I understand the difficulty with distribution dependencies, so I'd like to add a +1 to flatpak. Looking forward, it seems like an easier solution to streamline updates for future slack changes and it removes a significant effort for distribution integration testing.
Lastly, a hearty thanks to @raelgc and others that have kept this project going!
I have this problem on FreeBSD too. However, I see that ScudCloud reports the following things to stderr on startup:
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set1_groups
The --version reports:
- ScudCloud 1.63 (more specifically: 3d689139a0fa65813caf54ea5457727c6b48b432)
- Python 3.6.2
- Qt 5.7.1
- WebKit 602.1
- PyQt 5.7.1
- SIP 4.19.2
I'm using Python-3.6. Could it be about ScudCloud trying to use an SSL protocol variation, that Slack have disabled (a TLS1 vs. TLS-1.2 thing, for example)?
Interesting, I was not aware it was used in BSD :)
Unfortunately it's using the same webkit as Ubuntu 16.04.
I tried to get a list of dependencies of libqt5webkit5 in KDE Neon, but it's really crazy, the package is installed with broken dependencies. I checked in the "dev" version (which they said is bleeding edge). Maybe I'll need to install the "user" version (both are based on Ubuntu 16.04).
In this page, there are several versions of libqt5webkit5: https://reposcope.com/package/libqt5webkit5
Interesting, I was not aware it was used in BSD :)
Linux-users can download an official Linux client from Slack. It is the rest of us, who need alternatives...
Unfortunately it's using the same webkit as Ubuntu 16.04.
I upgraded everything on my office computer this week. In particular, the qt5-webkit port went from 5.7.1 to 5.212.0.a2. Should I try downgrading?
As far as I can tell the native Linux client isn't properly displaying native Linux notifications which is something I really like about Scudcloud.
As far as I can tell the native Linux client isn't properly displaying native Linux notifications which is something I really like about Scudcloud.
It does display notifications. It does not, however, set the URGENT hint on the window.
FWIW, I have an open ticket with Slack tech support to add the URGENT hint to their client.
URGENT hint to their client.
The only reason I mentioned the official Linux client above was to point out, that BSD-users need alternatives to it more than Linux-users -- because Linux-users can use the official client. This is true even if the official client has its own deficiencies.
Both @raelgc's being surprised about BSD users of his software and my reaction to his surprise were in comments with other information relevant to the problem discussed. Unfortunately, the three follow-ups since then were entirely off-topic... Let's all delete them, shall we?
I don't want to stray too far off-topic here, but just to flesh out the question "What's the point of ScudCloud today?" a little more:
Since this happened, I've been trying out the Slack native client again. I've been getting quite a lot of graphical glitches from the native client, like this
and using the 'Disable Hardware acceleration' option doesn't fix them. I've never had this problem with Scudcloud. While the official client is improving, if this webkit issue were to be resolved, I would personally switch back to Scudcloud for that reason.
It is also worth noting that the Slack native client is only made available as a .deb or a .rpm. While this covers a wide of linux users, there will be some users who benefit from the wider range of packaging formats supported by scudcloud and, of course, the availability of the source code. Also the fact that you make scudcloud available from PPAs etc is a nice convenience.
Your work on this is definitely appreciated :+1:
@UnitedMarsupials NO, please, no downgrade!
I'm sorry, I didn't listen :) It took me a while to downgrade the qt5-webkit port back to 5.7.1: I had to add a patch for compatibility with the new ICU-59 and wait hours for the recompile to finish.
But now I have two versions of the package built on my machine (with all other dependencies being the same) and have switched between them several times. Repeatedly and reproducably scudcloud works with 5.7.1 and does not work with 5.212...
Whether that really is the fault of the webkit, or, perhaps, scudcloud is doing something not quite correctly (but used to work), I do not know...
@UnitedMarsupials The issue is related to internal Slack JS not being properly interpreted by webkit.
Interesting your report. Arch users reported an issue some months ago related to newest webkit producing issues too.
Maybe if we can find a way to use webkit 5.7.1 in other distros... In Ubuntu 16.04, the default is 5.5.1 and as it stopped to work, we put a library in the ScudCloud repository to force 5.212.
So, we're in a range of versions with minimal and max version...
ScudCloud repository to force 5.212
You mean, to force 5.7.1? That's a work-around, but, because Linux distros and FreeBSD port-maintainers all consider @annulen's fork to be the "future", it can only be a temporary one. If it is a bug in webkit, @annulen will, hopefully, fix it soon. If it is something, scudcloud should fix or work aroud, you ought to do it :-/
Wish I could be of more help, but GUI is certainly not my forte...
FWIW, diligent has the same exact problem -- works with qt5-webkit-5.7.1, but not with the 5.212.a2.
Just wanted to add that I'm another person getting this error on Archlinux: ScudCloud 1.63 Python 3.6.0 Qt 5.8.0 WebKit 538.1 PyQt 5.8 SIP 4.19.1
I also wanted to say that I like scudcloud better than the "official" slack client. I hate that the Slack client automatically closes to the tray, doesn't work properly with my WM's icon system (shows a blank icon, good job guys), and is a ridiculous memory hog. While I recognize that slack in general is a ridiculous memory hog, I've found Scudcloud much more manageable. Plus I prefer FOSS solutions when possible. Please don't kill this project!
The official client also disabled going through a proxy on Linux. Raised a support case they said it was intentional and not going to be reversed. Scudcloud "just works" no matter if you are using a PAC file, manual settings, etc. No configuration required.
In short, official Linux Slack client is absolutely useless in a corporate environment. Scudcloud is not...
edit: if raelgc chooses to move onto new projects I totally understand. Just adding it to the list of problems he has helped overcome with Scudcloud
Downgrading webkit is hardly feasible as you need to manually downgrade a chain of dependencies... It's far from desirable.
I came work this morning to find my scudcloud window spinning again. I did not change any packages (still have WebKit 538.1 and PyQt 5.7.1). I did not even restart the client -- it was working yesterday, but no longer does.
I restarted it and now it hangs as described in this ticket -- showing the "message of the day" signed by "Your friends at Slack" and spinning the spinner.
Diligent is having the same problem. I'll see, if upgrading webkit may actually help now :)
@UnitedMarsupials that's the exact same thing that happened to me. No update, just restarted and it didn't work anymore. I ran a full system update on Sunday and still no cigar. I'd consider downgrading qt and webkit, but that would break my system considerably.
AH HA! This is exactly what mine does also in Fedora 26 x64.
Prior to Fedora updates, ait was working fine. Will delete my last comment in the other 'issue' as this is the exact issue that happens.
#crysx
I also have this error (infinite loading screen) in NixOS:
ScudCloud 1.63
Python 3.6.2
Qt 5.9.2
WebKit 538.1
PyQt 5.9
SIP 4.19.3
Changing user agent (in resources.py) to Mozilla/5.0 (X11; Linux x86_64) AppleWebKit (KHTML, like Gecko) Version/9.0 Safari fixes it for me.
ScudCloud 1.63
Python 3.6.3
Qt 5.10.0
WebKit 538.1
PyQt 5.9
SIP 4.19.3
Changing User Agent to the one mentioned by @ArturGaspar didn't fix the problem.
I also just tried the user agent switcheroo and it also didn't work for me.
My config, for reference:
ScudCloud 1.63
Python 3.5.2
Qt 5.5.1
WebKit 602.1
PyQt 5.5.1
SIP 4.17
Worked for me:
ScudCloud 1.63
Python 3.5.3
Qt 5.7.1
WebKit 538.1
PyQt 5.7
SIP 4.18.1
Where is the resources.py file? I looked in ~/.config/scudcloud, but all I have is scudcloud_qt5.cfg. I did a locate for resources.py, and came up with the following, none of which look relevant: /usr/lib/calibre/calibre/gui2/tweak_book/editor/insert_resource.py /usr/lib/calibre/calibre/gui2/tweak_book/editor/insert_resource.pyc /usr/lib/calibre/calibre/gui2/tweak_book/editor/insert_resource.pyo /usr/lib/python2.7/site-packages/pygments/lexers/resource.py /usr/lib/python2.7/site-packages/pygments/lexers/resource.pyc /usr/lib/python2.7/site-packages/pygments/lexers/resource.pyo /usr/lib/python2.7/test/test_resource.py /usr/lib/python2.7/test/test_resource.pyc /usr/lib/python2.7/test/test_resource.pyo /usr/lib/python3.6/test/test_resource.py
I too am happy to report, the User-Agent change fixes things. I used: Mozilla/5.0 (X11; FreeBSD amd64) AppleWebKit (KHTML, like Gecko) Version/9.0 Safari.
But only for the users of the older WebKit 538.1. Which means, there is still something about the new version of WebKit, that triggered the original problem.
Where is the resources.py file?
Wherever your Python installs packages. On my system, it is in /opt/lib/python3.6/site-packages/scudcloud/resources.py.
User Agent trick did not work for me either. I tried both @ArturGaspar and @UnitedMarsupials string, and both fail without additional errors. For reference: ScudCloud 1.63 Python 3.6.2 Qt 5.9.2 WebKit 602.1 PyQt 5.9 SIP 4.19.3
Tried downgrading (python-pyqt5 & qt5-webkit), and got this when running scudcloud --version, so not sure if it's even possible to downgrade, or if I missed a package:
Traceback (most recent call last):
File "/usr/bin/scudcloud", line 11, in
Another where the useragent hack didn't work (sadly, I wish I could post an exception to the rule); Fedora 26:
ScudCloud 1.63
Python 3.6.2
Qt 5.7.1
WebKit 602.1
PyQt 5.8.1
SIP 4.19.1
Attempting to downgrade via dnf downgrade python3-qt5-webkit tells me I'm already at the lowest available version :(
USER_AGENT hack works for me atm. I run a virtualenv python3, and install scudcloud from source.
ScudCloud 1.63
Python 3.5.3
Qt 5.7.1
WebKit 538.1
PyQt 5.7
SIP 4.18.1
My sympathy for the author doing the mouse and cat game with Slack. Your work is the inspiration.
Hi,
fresh install of scudcloud, not bein able to log in... Ubuntu 16.4
~ scudcloud --version
ScudCloud 1.63
Python 3.5.2
Qt 5.5.1
WebKit 602.1
PyQt 5.5.1
SIP 4.17
Workaround for Fedora 26 x86_64
1. Downgrade WebKit packages
# dnf downgrade qt5-qtwebkit python3-pyqt4-qtwebkit
2. Change User Agent in scudcloud/resources.py
USER_AGENT = 'Mozilla/5.0 (X11; FreeBSD amd64) AppleWebKit (KHTML, like Gecko) Version/9.0 Safari'
What's installed after downgrade
$ scudcloud --version
ScudCloud 1.63
Python 3.6.2
Qt 5.7.1
WebKit 538.1
PyQt 5.8.1
SIP 4.19.1
$ rpm -q python3-PyQt4 python3-PyQt4-webkit qt5-qtwebkit scudcloud
python3-PyQt4-4.12-3.fc26.x86_64
python3-PyQt4-webkit-4.12-3.fc26.x86_64
qt5-qtwebkit-5.7.1-5.fc26.x86_64
scudcloud-1.63-1.fc26.noarch
After downgrading and changing the USER_AGENT property scudcloud is working on Fedora 26
Works fine here on Ubuntu 14.04
ScudCloud 1.63
Python 3.4.3
Qt 5.2.1
WebKit 602.1
PyQt 5.2.1
SIP 4.15.5
@annulen we're discussing it's not working on the latest software, not on older like 14.04...
You are discussing (potential) regression in QtWebKit, this is the latest QtWebKit available (see 602.1)
Works fine here on Ubuntu 14.04
Thinking, perhaps, Slack have changed something about their app, I just tried to update my qt5-webkit back to 5.212.a2 on FreeBSD. I'm sorry to say, things remain broken.
Perhaps, it is some the differences in some other package-versions between my and @annulen's setup. I have:
- ScudCloud 1.63
- Python 3.6.3
- Qt 5.7.1
- WebKit 602.1
- PyQt 5.7.1
- SIP 4.19.2
But downgrading just the webkit back to 538.1 fixes things... Also, as we found earlier, Diligent does not work for me either with the new WebKit, but it worked for @annulen...
Slack have changed something about their app
I checked it right before posting the message. Something indeed changed, but certainly not in Slack site.
Something indeed changed, but certainly not in Slack site.
Are you alluding to a commit into webkit? Could you link to the diff -- I'll be happy to try it!
Are you alluding to a commit into webkit?
No. I didn't fix anything because I couldn't ever reproduce the issue
I couldn't ever reproduce the issue
Could you try with the other packages updated?
@UnitedMarsupials Please try this patch: annulen/webkit@5648446933f52fe479d0a9006f6393a81a790116
Please try this patch: annulen/webkit@5648446
Sorry for the delay, but this is good news. I'm delighted to confirm, the patch -- which boils down simply to:
--- Source/JavaScriptCore/runtime/JSGlobalObject.cpp
+++ Source/JavaScriptCore/runtime/JSGlobalObject.cpp
@@ -458,7 +458,10 @@ m_ ## lowerName ## Prototype->putDirectWithoutTransition(vm, vm.propertyNames->c
putDirectWithoutTransition(vm, vm.propertyNames->TypeError, m_typeErrorConstructor.get(), DontEnum);
putDirectWithoutTransition(vm, vm.propertyNames->URIError, m_URIErrorConstructor.get(), DontEnum);
+#if !PLATFORM(QT)
+ // Disable ES6 Proxy because our implementation is not compliant with what real world code expects
putDirectWithoutTransition(vm, vm.propertyNames->Proxy, ProxyConstructor::create(vm, ProxyConstructor::createStructure(vm, this, m_functionPrototype.get())), DontEnum);
+#endif
#define PUT_CONSTRUCTOR_FOR_SIMPLE_TYPE(capitalName, lowerName, properName, instanceType, jsName) \
helps and even the changing of USER_AGENT is no longer necessary...
Thanks @UnitedMarsupials. I'll try to build a Ubuntu webkit package with this patch.