Closed Bug 460919 Opened 15 years ago Closed 13 years ago

Remove descriptor limit changes once Flash 10 is widely deployed

Categories

(Camino Graveyard :: Plug-ins, defect)

All
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Camino2.1

People

(Reporter: alqahira, Assigned: alqahira)

Details

Attachments

(1 file)

Now that Flash 10 is out and has a fix for the resource leak, we can hopefully start a countdown to removing our compensation for that leaking.
Steven Michaud brought up the point yesterday on IRC (in discussion of a different bug) that the latest version of Flash that Apple has shipped with the Mac OS is still 9.0something. Do we want to use "Apple ships Flash 10" as a benchmark for when to do this, or are we assuming our users are generally smart enough to realise, "Hey, there's a new version of Flash out and upgrading would be a good idea"?

I'd personally be in favour of shipping 2.0 with that limit removed, since by the time we get 2.0 out the door, Flash 10 will have been final for at least a couple of months, but I realise that's probably on the aggressive side.

cl
Hardware: PC → All
(In reply to comment #1)
> Do we want to use "Apple ships Flash 10" as a benchmark for when to do this

I don't see the relevance of that as a marker; the majority of our users aren't going to rush out and buy the latest OS. I don't see a major OS upgrade as significantly more likely than a user updating Flash.

The limit change isn't hurting anything; I see no reason to remove it for 2.0, thus giving a bunch of users a worse experience.
Fwiw, Apple has in the past included the latest Flash release with security upgrades, like this one :
http://support.apple.com/kb/HT1897
JFTR, Apple has now shipped 10.0r22 to all 10.5.7 users (except cl), so we can start the countdown now, but I don't think we should consider taking this before Camino-whatever-is-after-2.0.
We should monitor our 10.4 stats (Security Update 2009-005 updated Flash to 9.0.246.0) and whatever information we can get from bug 514815.
Looking at analytics stats from the last two weeks on cb.o, about 70% of users are on Flash 10, so we have a pretty big chunk left. We should take another look once most people are on Camino 2; dropping 10.3 from the equation will shift the pie in our favor (I can't do Flash breakdowns by OS now because almost everyone uses 1.6, which doesn't report OS).
This isn't critical for 2.1 by any means, but we should take another look at these stats now that 2.0 is out (heh!) and now that we'll be doing flash-check on updates.

Assuming, of course, Flash 10.1 hasn't regressed this :P
Flags: camino2.1?
cb.o analytics for 2.0 users show only ~3% of people still on Flash 9, so I say we pull this code out for 2.1.
Stuart, it looks like you added time.h when you did the initial breakpad impl (http://hg.mozilla.org/camino/diff/cd95a35c8352/src/application/main.m), I assume to support "time", but didn't remove it when that code went away (http://hg.mozilla.org/camino/diff/aa828e7841da/src/application/main.m).  I've removed it, too.

I don't see anything else that looks like it requires any of those <sys/foo.h> imports, and I've successfully built and triggered Breakpad with them removed, so, as long as Flash hasn't regressed its descriptor fix, I think this is OK.  (Getting this in before a1 would be good, so we can get some sanity-checking beforehand from nightly users, and then more widespread testing in a1 itself.)
Assignee: nobody → alqahira
Status: NEW → ASSIGNED
Attachment #495999 - Flags: superreview?(stuart.morgan+bugzilla)
Flags: camino2.1? → camino2.1a1?
Target Milestone: --- → Camino2.1
Comment on attachment 495999 [details] [diff] [review]
Rip out descriptor changes and associated headers (plus one leftover from Breakpad)

sr=smorgan, thanks for doing this.
Attachment #495999 - Flags: superreview?(stuart.morgan+bugzilla) → superreview+
http://hg.mozilla.org/camino/rev/86d3f756d63e
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: camino2.1a1? → camino2.1a1+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.