Closed Bug 1042627 Opened 10 years ago Closed 10 years ago

Treeherder prompts for Flash use


(Tree Management :: Treeherder, defect, P2)

Windows 7


(Not tracked)



(Reporter: jimm, Assigned: mdoglio)




(1 file)

This prompted me to allow flash to run. IMO, we should rely on 3rd party plugins for internal tools. FWIW, denying plugin use didn't seem to break anything.
/should/shouldn't !
Bug 1030710 removed the "copy to clipboard" use of flash - I can't see anything else that uses it - other than a fallback [1], but we shouldn't be hitting that in a recent browser?

Could you paste the swf URL?

(I agree we shouldn't be using flash in our tools)

Priority: -- → P2
Summary: Tree herder prompts for Flash use → Treeherder prompts for Flash use
Flags: needinfo?(jmathies)
(In reply to Ed Morley [:edmorley] from comment #2)
> Bug 1030710 removed the "copy to clipboard" use of flash - I can't see
> anything else that uses it - other than a fallback [1], but we
> shouldn't be hitting that in a recent browser?
> Could you paste the swf URL?

I can't trap it. The plugin object tag/window are created initially but appear to get removed shortly after they show up and we prompt. Allowing it to load doesn't provide any useful info in the plugin instance code, there's no src url and the object tag is created by script. Dev tools doesn't seem to understand the treeherder page at all (the network view is empty), and page info provides no plugin data.  

the url of the page is:

I can see the plugin click-to-play frame briefly in the lower left side of the page during page load.
Flags: needinfo?(jmathies)
Hmm, still not sure. Seems to load up about the same time || loads based on dev tools -> network -> html loads view.
So I'm seeing an <object> inserted by this code:

This is unconditionally creating an <object> with type="application/x-shockwave-flash" and sticking it into the DOM.

Specifically the relevant bit is (prettyprinted, but still with the crap minified names, sorry):

            var r = "object",
                q = "application/x-shockwave-flash";

            function C(X) {
                return j.createElement(X)

            function V() {
                var X = j.getElementsByTagName("body")[0];
                var aa = C(r);
                aa.setAttribute("type", q);
                var Z = X.appendChild(aa);

followed by doing Z.GetVariable("$version") and the like.  Complete with a settimeout poll for that version to be available.  Then once is has the version or has spent 100ms polling, whichever comes first:

This looks relevant:

Do we just need to build a custom then?
Flags: needinfo?(cdawson)
edmorley I think that's exactly what we need to do. We will be landing a PR for it shortly. The swf loading is being done here:

It's a minified js line containing the SWFObject module. We commented that out locally and also prevented the initialization of the FlashSocket here:

This prevents the swf from ever being loaded and minimizes any related js console errors assuming the conditions for falling back to FlashSocket usage are not met at runtime. Most certainly a hack but gets the job done.
Flags: needinfo?(cdawson)
The github issue linked in comment 6 implies this could be scripted, via a custom generated build on; the approach in comment 7 sounds good short term - but might the generated approach make it easier to track updates in the future?
The solution described here,, would definitely be preferable but I'm unable to get a local build to work at the moment, will investigate a bit more.
The attached PR disable the flash transport method for There are no flash warnings on my machine with this applied, let me know if the problem still persists
That's great - thank you :-)

I was looking into this a bit more and noticed 1.x is also now out - but that can be dealt with later on - filed bug 1043292 for that.
Assignee: nobody → mdoglio
Attachment #8461391 - Flags: feedback+
Moving to is more complicated than you would expect. Out server side implementation of the server is based on a python library (gevent-socketio) so we need to wait for this library to be updated to support the new client. I'll add some details on bug 1043292.
This merged and so can be marked as fixed right?
Yep, I'm closing it
Closed: 10 years ago
Resolution: --- → FIXED
(In reply to Kyle Huey [:khuey] ( from comment #16)
> Has this been deployed yet?  Because
> still wants to use flash on my machine.

We are going to push it to production today
Commits pushed to master at
Prevent flash warning (bug 1042627)

I produced a custom build of the client to not include the
flash transport implementation. I also upgraded its version to the
latest release on the 0.9 branch.
Merge pull request #105 from mozilla/disable-socketio-flash

Disable socketio flash (bug 1042627)
You need to log in before you can comment on or make changes to this bug.