[2:10pm] pinkerton: i think we should also default to "don't let sites change window sizes" on [2:10pm] ss: I'd agree with that. [2:11pm] ardissone|away: me too [2:11pm] pinkerton: that's so totally useful and safari doesn't, and it's hidden away [2:11pm] • ardissone|away tries to remember what sites it breaks We have at least one old closed bug about a site that opens a tiny window, inserts an image, and then resizes the window to fit the image. I seem to recall maybe one other site I've run across that is broken with this enabled, but I'm guessing not many major sites rely on those features.
I don't remember ever running into problems with this, and I have it enabled since whenever that was implemented (that is, Mozilla 1.0 or something ?).
I remember running into lots of annoying problems with it *off*, and zero with it on, so I'd be in favour of this as well.
Confirming per the meeting; we'll at least do this on the trunk. mento, do you have any strong opinion about doing this branch-and-trunk vs. trunk-only? Stuart expressed concern at the meeting we wouldn't get enough exposure before 1.6.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've run with this turned on ever since it existed, but I understand the exposure thing, so I'm OK either way. One thing to remember is that alphabeta testers are usually existing users, and so, they usually have existing profiles, and won't be affected by a default change no matter when we roll it out.
(In reply to comment #4) > testers are usually existing users, and so, they usually have existing > profiles, and won't be affected by a default change no matter when we roll it > out. Since prefs.js in 90% of the cases is just a diff against all.js/all-camino.js, the only users who wouldn't be moved are people who have a differing value set--and in this case (since it's a bool), they have the value we want already. I'll verify this later with a test profile, but I'm sure that's what will happen here ;)
Comment 5 accurately describes what happens (and if someone already has the pref enabled, those entries are removed from their prefs.js, since their setting becomes the default). There's now a testcase for move and resize in the URL field.
Created attachment 300811 [details] [diff] [review] Like so
Assignee: nobody → alqahira
Status: NEW → ASSIGNED
Attachment #300811 - Flags: review?(cl-bugs)
Comment on attachment 300811 [details] [diff] [review] Like so Looks good to me.
Comment on attachment 300811 [details] [diff] [review] Like so I'm on a trip and haven't been on irc for a couple of days, so OK, as long as there's been an in-channel discussion of the above concerns.
Attachment #300811 - Flags: superreview?(mark) → superreview+
[1:01pm] pinkerton: i say let's just do it [...] [1:40pm] ardissone|away: hmm [1:40pm] ardissone|away: will flipping that pref affect any tinderbox tests? [1:40pm] ardissone|away: as in, make them fail? [1:41pm] pinkerton: good q [1:42pm] ardissone|away: we can flip it off for the tinderboxen somewhere if so I'll land this later when I can watch closely and back out if we need to modify the tinderbox test config.
Target Milestone: --- → Camino1.6
Checked in on branch and trunk; I'll monitor boxset for bizarre T* results or orangeness and back out if we'll need to twiddle things in the tinderbox.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
No orange on boxset. We may or may not have experienced a *very* slight Tdhtml increase: Before: 833,829,833,833,824 = 830.4 avg After: 837,827,834,837,830 = 833.0 avg That works out to approx 0.31% regression, or noise ;)
You need to log in before you can comment on or make changes to this bug.