X crashed while opening a huge[dimensions not space] image in Midori.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Midori Web Browser |
Incomplete
|
Undecided
|
Unassigned | ||
elementary OS |
New
|
Undecided
|
Unassigned |
Bug Description
Pretty sure this is what the issue was but I came back from a reboot first so. Yeh, I don't think apport did this right and I can't see it in the logs. It was X related though as well. Was opening a small but massive PNG with Midori. After reboot the PNG also lagged up [to a crawl for 5min] Photos even though it was only 20MB. If you want to duplicate just use debtree and dot then open the result ;).
ProblemType: Bug
DistroRelease: elementary OS 0.3
Package: elementary-desktop 1.349+393~
ProcVersionSign
Uname: Linux 3.13.0-34-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.3
Architecture: amd64
CrashDB: elementary_meta
CurrentDesktop: Pantheon
Date: Fri Aug 15 05:33:00 2014
InstallationDate: Installed on 2014-08-10 (4 days ago)
InstallationMedia: elementary OS 0.3 "Freya" - Daily amd64 (20140810)
ProcEnviron:
LANGUAGE=en
PATH=(custom, no user)
XDG_RUNTIME_
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: elementary-meta
SuspiciousXErrors:
ThirdParty: True
UpgradeStatus: No upgrade log present (probably fresh install)
description: | updated |
description: | updated |
Changed in midori: | |
status: | New → Incomplete |
By default webkitgtk tries to scale down images to fit the screen. In case of a very big image or/and older machine it can exhaust all of the cpu and memory sometimes. This is what you probably experience here.
You can istruct midori to not try to scale down images by putting a shrink- images= false" in your midori config file under settings.Note that this is a setting for all pages (if you wanna toggle it runtime you may use statusbar features extension and add it yourself) and in case of a bigger image it would make you scroll to view the whole image.
"auto-