Bug 1223720 - Konqueror starts downloading hidden video on start.fedoraproject.org, even when it's not exposed and has to be killed
Summary: Konqueror starts downloading hidden video on start.fedoraproject.org, even wh...
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kde-baseapps
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-21 10:25 UTC by David Howells
Modified: 2015-05-26 13:41 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-05-23 00:11:38 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Compressed wireshark capture file showing konqueror starting up (5.95 MB, application/x-xz)
2015-05-21 10:25 UTC, David Howells
no flags Details

Description David Howells 2015-05-21 10:25:13 UTC
Created attachment 1028068 [details]
Compressed wireshark capture file showing konqueror starting up

Description of problem:

When konqueror opens the start.fedoraproject.org page, there's a hidden video that a kioslave starts pulling immediately:

    https://mattdm.fedorapeople.org/council/2015-05-11_Fedora-Council_Subproject-Status-Marketing.webm

despite the fact it's not exposed.  Konqueror won't then go away but has to be killed.

I didn't realise this was happening until I hit the ISP's monthly bandwidth cap on the 18th of the month having apparently inadvertently downloaded around 24G from this file during working hours.

I used wireshark to capture a trace (attached) which shows almost 8000 packets being shifted in around 15 seconds.  Konqueror is started 15 seconds into the trace (at packet 2) and killed at about 30 seconds in (at around packet 7600).

The vast majority of packets are to/from local TCP6 port 56477, starting with packet 51.

Address 2001:8b0:194:0:96de:80ff:feb4:ecc3 is my home machine (warthog).

Address 2610:28:3090:3001:5054:ff:fedb:7f5a is {mattd,mattdm}.fedorapeople.org - though there's no reverse DNS mapping for it, the server name can be picked out of the opening TLS packet.

Grabbing the source for the start page, the only URL to mattd is this:

<img src="https://mattdm.fedorapeople.org/council/2015-05-11_Fedora-Council_Subproject-Status-Marketing.webm">

which seems to be placing a streaming video as a static image.  The video should be hidden according to the previous line:

<div class="col-xs-1 col-sm-1 hidden-xs">

and shouldn't be played until it is exposed.

It appears that the IMG tag is assumed to be a static image (or an animated image) and just downloaded to the cache by the kioslave - with bad results when the image turns out to be video.

Version-Release number of selected component (if applicable):

konqueror-15.04.0-1.fc21.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Start konqueror at start.fedoraproject.org
2. Observe lights on switch go beserk as the kioslave hammers the network.
3.

Comment 1 David Howells 2015-05-21 10:32:25 UTC
This problem affect Chrome also.

Comment 2 Rex Dieter 2015-05-22 20:02:16 UTC
I suspect the website code doesn't work as intended, probably ought to raise issue with websites team.

Comment 3 Rex Dieter 2015-05-22 20:05:39 UTC
Opened ticket,

https://fedorahosted.org/fedora-websites/ticket/327

Comment 4 David Howells 2015-05-22 22:26:16 UTC
The website has already been fixed.  However, it may be worth limiting the amount of data that will be downloaded for an IMG tag, just in case something like this happens again.  Also, if I close my browser, the IMG tag downloads it is waiting for should perhaps be aborted rather than accruing konqueror corpses.

Comment 5 Rex Dieter 2015-05-23 00:09:16 UTC
Sounds like a potentially good report/feature-request for upstream (at bugs.kde.org)

Comment 6 Rex Dieter 2015-05-23 00:11:38 UTC
Closing (cantfix here, upstream needs to implement the fix/feature), and since the immediate problem is fixed.

Comment 7 David Howells 2015-05-26 12:32:54 UTC
Should I raise it?

Comment 8 Rex Dieter 2015-05-26 13:41:14 UTC
That's up to you, if you want.


Note You need to log in before you can comment on or make changes to this bug.