Vivaldi constantly freezes on different websites



  • Since today I constantly encounter freezes (e.g. on faz.net and achgut.com or links on those pages).
    It is not related to the ad-blocker (someone else's problem in another post). I switched the ad-blocker off and Vivaldi still freezes. It is neither related to the number of tabs (another post). Freeze can happen on the very first tab. There is no response anymore but the program can be terminated without using system monitor or terminal. I updated my version to ...46.1 (I didn't before as I don't use Ubuntu but Debian Testing) to make sure but the freezes still happen.

    Edit: Vivaldi froze on vivaldi.net when logging out of the forum after writing this post.



  • Hi, checked pages and open several links from them in background or direct.
    No freeze on:
    Vivaldi 1.7.705.3 (Official Build) dev (64-bit)
    Opensuse Leap 42.1 x86_64
    CPU Intel T4200 4 GB
    GPU Intel GN 965
    xf86-video-intel 2.99.917-6.1
    Vivaldi latest snapshot
    uBlock Origin

    Btw. FAZ page is 4MB with tons of images on first page, tsts.
    Iirc a webpage should not have more than 7 links or headers, N24 and NTV are the same crap.
    This is only my opinion and has nothing to do with your report.

    Cheers, mib



  • @mib2berlin
    Current stable is unusable for me. It freezes constantly, yesterday after editing my post. Today when trying to log into this forum.



  • @ghpy said in Vivaldi constantly freezes on different websites:

    @mib2berlin
    Current stable is unusable for me. It freezes constantly, yesterday after editing my post. Today when trying to log into this forum.

    Try with a new profile. In your terminal run vivaldi --user-data-dir=vivaldi-test-profile
    This will create and run vivaldi using ~/vivaldi-test-profile as the profile directory.
    When finished testing you can delete the folder ~/vivaldi-test-profile.



  • @CantankRus said in Vivaldi constantly freezes on different websites:

    Try with a new profile. In your terminal run vivaldi --user-data-dir=vivaldi-test-profile

    Nice try but didn't help.
    First launch seemed to work fine. Ten minutes without freezing. Normally Vivaldi currently doesn't reach five. But then I tried to print something and the print screen did not appear, just a big grey transparent cross overlaying the page. Terminal said:
    [257:257:1228/085530:ERROR:render_media_log.cc(29)] MediaEvent: PIPELINE_ERROR demuxer: could not open
    After that Vivaldi didn't freeze but didn't work either. Loading other pages seemed to work in the background (lots of traffic) but the page was not displayed. Terminal said
    [538:538:1228/090014:ERROR:render_media_log.cc(29)] MediaEvent: PIPELINE_ERROR demuxer: could not open
    Second launch from terminal Vivaldi froze before having loaded the first website.
    [72:72:1228/090415:ERROR:KeyboardEventManager.cpp(344)] Not implemented reached in static bool blink::KeyboardEventManager::currentCapsLockState()
    Getötet



  • @ghpy You have a problem with video codecs.
    Please install chromium-codecs-ffmpeg-extra package as described in https://gist.github.com/ruario/bec42d156d30affef655

    The Intel Xorg driver has some problems with hardware acceleration and opengl. On some GPU this results in freezes or slow reaction.
    Perhaps my blog article https://labs.gwendragon.de/blog/Web/Browser/Vivaldi/slow-or-flickering-video-with-vivaldi-on-linux may help.



  • @Gwen-Dragon
    I'll try that but it doesn't seem to make sense to me.

    Why does Vivaldi need exotic codec packages that are not included in Debian's repositories to log me into this forum which does not seem to contain audio or video content? Other browsers can log me into forum.vivaldi.net without this conundrum.

    Why does Vivaldi all of the sudden freeze without this codec package instead of showing a message like "Content cannot be displayed for lack of codec" or something like that?

    Edit: It didn't make sense to me and it didn't to Vivaldi either. I installed the codecs but Vivaldi freezes just the same.



  • The codec package has nothing to do with logins in forums.
    Vivaldi uses the non-free chromium codecs extra package and if you don't have them, video decoding will fail. Debian maintainers don't provide non-free codecs.

    Some freezes are related to Adblocker extensions.
    Some freezes are related to OpenGL, graphics GPU and its drivers.
    Some related to memory overflows while loading a webpage because of bad designed JS.
    Some are related to use of unstable Debian versions.

    I cant reproduce it on your mentioned pages. They work on my Debian 8.6.



  • @Gwen-Dragon
    As mentioned I switched the adblocker off, to make sure. As far as I can tell the freezes can occur on any page, independent of content. If Vivaldi freezes on a certain page this doesn't mean that it will do so again with the same page (and the other way around). It is the same with vivaldi-snapshot.
    As it didn't start after a change of Vivaldi's version the only possibility in my opinion is a conflict between Vivaldi and the packages I did upgrade the day before:

    Commit Log for Sun Dec 25 12:52:11 2016

    Die folgenden Pakete wurden entfernt:
    xserver-xorg-input-vmmouse
    xserver-xorg-video-sisusb

    Die folgenden Pakete wurden aktualisiert:
    libodbc1 (2.3.1-4.1) to 2.3.4-1
    man-db (2.7.5-1) to 2.7.6.1-2
    nano (2.7.1-1) to 2.7.2-1
    python-pexpect (4.2.0-1) to 4.2.1-1
    python-pexpect-doc (4.2.0-1) to 4.2.1-1
    python3-pexpect (4.2.0-1) to 4.2.1-1
    vim-common (2:8.0.0095-1) to 2:8.0.0134-1
    vim-tiny (2:8.0.0095-1) to 2:8.0.0134-1
    xserver-common (2:1.18.4-1) to 2:1.19.0-2
    xserver-xephyr (2:1.18.4-1) to 2:1.19.0-2
    xserver-xorg-core (2:1.18.4-1) to 2:1.19.0-2
    xserver-xorg-input-evdev (1:2.10.4-1) to 1:2.10.4-1+b1
    xserver-xorg-input-libinput (0.22.0-1) to 0.23.0-1
    xserver-xorg-input-mouse (1:1.9.2-1) to 1:1.9.2-1+b1
    xserver-xorg-input-synaptics (1.9.0-1) to 1.9.0-1+b1
    xserver-xorg-input-wacom (0.33.0-1) to 0.33.0-1+b1
    xserver-xorg-video-amdgpu (1.2.0-1) to 1.2.0-1+b1
    xserver-xorg-video-ati (1:7.8.0-1) to 1:7.8.0-1+b1
    xserver-xorg-video-cirrus (1:1.5.3-1+b1) to 1:1.5.3-1+b2
    xserver-xorg-video-fbdev (1:0.4.4-1+b4) to 1:0.4.4-1+b5
    xserver-xorg-video-intel (2:2.99.917+git20161105-1) to 2:2.99.917+git20161206-1
    xserver-xorg-video-mach64 (6.9.5-1+b1) to 6.9.5-1+b2
    xserver-xorg-video-mga (1:1.6.4-1+b2) to 1:1.6.4-2+b1
    xserver-xorg-video-neomagic (1:1.2.9-1+b1) to 1:1.2.9-1+b2
    xserver-xorg-video-nouveau (1:1.0.13-1) to 1:1.0.13-1+b1
    xserver-xorg-video-r128 (6.10.1-1) to 6.10.1-2+b1
    xserver-xorg-video-radeon (1:7.8.0-1) to 1:7.8.0-1+b1
    xserver-xorg-video-savage (1:2.3.8-1+b1) to 1:2.3.8-2+b1
    xserver-xorg-video-tdfx (1:1.4.6-1+b2) to 1:1.4.6-2+b1
    xserver-xorg-video-trident (1:1.3.7-1+b2) to 1:1.3.7-2+b1
    xserver-xorg-video-vesa (1:2.3.4-1+b1) to 1:2.3.4-1+b2
    xserver-xorg-video-vmware (1:13.2.1-1) to 1:13.2.1-1+b1
    xxd (2:8.0.0095-1) to 2:8.0.0134-1

    Die folgenden Pakete wurden installiert:
    libxfont2 (1:2.0.1-3)



  • Dass Vivaldi unreproduzierbar einfriert, sieht für mich nach einer Inkompatibilität mit deinem Linux aus.
    In der Konsole gestartet ist da dann nicht sichtbar, oder?

    Vielleicht kommt ein Nutzer mit Testing, aber Debian-Leute sind hier seltener, die meisten haben Mint, Arch oder Ubuntu.

    Auf Debian Testing releases hat wohl noch niemand Vivaldi ausprobiert. Vivaldi auf Testing und Experimental releases zu bauen ist für die Entwickler ja nicht praxisnah.



  • @Gwen-Dragon said in Vivaldi constantly freezes on different websites:

    In der Konsole gestartet ist da dann nicht sichtbar, oder?
    [...]
    Auf Debian Testing releases hat wohl noch niemand Vivaldi ausprobiert. Vivaldi auf Testing und Experimental releases zu bauen ist für die Entwickler ja nicht praxisnah.

    In der Konsole gestartet kommen die o.g. Fehlermeldungen. In syslog etc. kommt nichts.
    Natürlich können die Vivaldi-Entwickler Debian Testing als irrelevant ignorieren. Allerdings landen die Pakete von Testing später in Stable und zumeist auch in Ubuntu und Mint. Von daher würde ich die Probleme, die m.E. vermutlich eine Folge der Aktualisierung der xserver-Pakete sind, nicht auf die leichte Schulter nehmen.



  • I cannot reproduced freezes with/out Extensions.
    But i use Siduction based on Debian/sid (unstable)

    When start Vivaldi 1.7.705.4 dev and open faz.net:

    $ vivaldi
    [13843:13869:1229/124820:ERROR:nss_util.cc(809)] After loading Root Certs, loaded==false: NSS error code: -8018
    
    A Parser-blocking, cross-origin script, http://qs.ioam.de/?faz//CP//FazOooOooHom114//VIA_SZMNG, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity. See https://www.chromestatus.com/feature/5718547946799104 for more details.
    A Parser-blocking, cross-origin script, http://static.chartbeat.com/js/chartbeat_mab.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity. See https://www.chromestatus.com/feature/5718547946799104 for more details.
    [WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED
    
    $ inxi -SCG
    System:    Host: sid Kernel: 4.9.0-towo.1-siduction-amd64 x86_64 (64 bit) Desktop: Xfce 4.12.3
               Distro: siduction 14.1.0 Indian Summer - xfce - (201411230427)
    CPU:       Quad core Intel Core2 Quad Q9400 (-MCP-) cache: 3072 KB 
               clock speeds: max: 2666 MHz 1: 2666 MHz 2: 2666 MHz 3: 2666 MHz 4: 2666 MHz
    Graphics:  Card: NVIDIA G94 [GeForce 9600 GT]
               Display Server: X.Org 1.19.0 driver: nvidia Resolution: [email protected]
               GLX Renderer: GeForce 9600 GT/PCIe/SSE2 GLX Version: 3.3.0 NVIDIA 340.101
    


  • It seems to be an incompatibilty of xserver 1.19 with Chromium/Vivaldi (or vice versa, whichever way you prefer).
    https://kororaproject.org/support/engage/question/bugs-after-upgrade-1
    refers to
    https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1399396
    See comment 36. On my system the problem started with the upgrade from 1.18 to 1.19 as well.

    Edit: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846779
    I never understand why packages causing serious problems make it into Testing weeks after the bug report was filed.
    According to one post in the report Chrome does not freeze starting it with --disable-gpu . Vivaldi starts with this option but so far I can't tell whether it is a workaround for the time being.



  • Starting Vivaldi with --disable-gpu option prevents it from freezing under xserver 1.19. In addition Vivaldi starts much quicker than without the option.



  • @ghpy said in Vivaldi constantly freezes on different websites:

    Starting Vivaldi with --disable-gpu option prevents it from freezing under xserver 1.19. In addition Vivaldi starts much quicker than without the option.

    Deactivate the hardware acceleration on chrome://settings/search#hardware and starting Vivaldi without --disable-gpu
    I hope this help.



  • @ghpy
    Yeah, that's the problem for Debian Testing.

    If packages had been in sid for sometime, it will move to testing first even if bug reports or breakage filed and as long it's not hard dependency break. For rule of thumb; if broken packages only effect optional or standard priority package, that broken package still good to enter testing.

    It's a known rule for Debian testing, "If it's break, you keep the pieces".
    For me it's more hell in testing if it's break, due fix could come weeks or months. Been there, done that, no thank you.

    Linux/Debian sid amd64 and happy. :grin:



  • As i already said with Testing: instable drivers and X server and GPU problems.

    In past i used Debian 7 Testing or Sid with Opera 11-12 and newer Operas and that was sometimes more of experimental than a working Linux. On some GPU teh Xserver drove me crazy crashing ow slowdown rendering.
    Thats the reason why i dont use Testing anymore on a workstation.



  • (/topic/13119/vivaldi-constantly-freezes-on-different-websites/16):

    Linux/Debian sid amd64 and happy. :grin:

    I've heard that several times from different people but I still don't see the logic. A lot more bugs hit sid than testing, that's what sid is for. If a serious bug hits testing it hits later and I can get the fixed package from sid at the same time as in sid. Just needs a temporary change of repo. Had it twice this year, once gtk and now xserver.



  • @ghpy
    I can't defend from that. A lot of things matter for choice of tools we want to use, right?
    sid does more buggy than testing, it's also far less buggy than experimental. Don't fret, I don't mock anyone for freedom of choice.

    For me, the good about sid, fixes come faster. Vivaldi snapshot anyone? While on testing, the situation I mentioned above could stick in for months. Remember, testing can be picture as mix and match for stable. They could broken for rest of half year or even years without no body really care.

    Probably the only thing I can is give is tips how to live on sid.

    • Watch out incoming new libc families.
    • Watch out incoming xorg.
    • Watch out incoming systemd. (If you use it).
    • Watch out incoming kernel.
    • Watch out incoming hardware libraries.
    • It help to lengthen your life if you just forget to use big Desktop Environments.
      These a few rules I set for my self. Luckily, it also fit if you like to use rolling distro such as Arch.

    Ah, okay. Seem I wander too far from thread topic.



  • Same thing also on W7 Pro 8(
    I've been testing Live Distros... I like Xfce, but GNOME & KDE has built-in color management. I'm leaning towards Fedora Spins at this point.


Log in to reply
 

Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.