[webkit-dev] Feature Announcement: Adding <iframe seamless>

[Jarred Nicholls]

On Wed, May 2, 2012 at 2:03 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On May 2, 2012, at 6:14 AM, Jarred Nicholls <jarred at webkit.org> wrote:
>
> On Tue, May 1, 2012 at 7:39 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>>
>> I'm not too picky about how it's done, but I'd feel more comfortable with
>> #ifdef protecting the code changes rather than if(). If the changes are so
>> entangled that it's not easy to put only the changes in an ifdef, then I
>> would be skeptical that they actually have no possible effect on the
>> non-seamless case.
>
>
> Do we not have sufficient tests to lend us more confidence in this area?
>
>
> There's no amount of automated testing that would make me comfortable with
> landing a major feature today and shipping it to customers tomorrow
> (exaggerated case, but this is the kind of thing we're talking about).
>

I wholeheartedly agree, and agree #ifdefs provide safety in this regard.

I was speaking more towards the skepticism that the runtime conditional
checks were not adversely affecting the non-seamless case.  I would hope to
think that our automated tests were (or will be) abundant and thorough
enough to prove with some level of confidence that what Adam suggests would
work.  If that isn't the outcome, then one could argue tests are worthless
in all situations.

#ifdefs are valuable and necessary for the reasons you stated, particularly
security and bugs in new exposed features.  These things ought to be
gradually exposed, starting with explicit opt-ins.  But, aside from that
and as a separate issue really, I would hope to think that our tests
properly mitigate concern for regressions on code that is being modified.


>
> Nearly every significant feature has had security holes or site
> compatibility issues discovered post-landing, even if it passes all tests.
> That's why things like this need bake time; it can take from a few weeks to
> a few months of being enabled on trunk for a new feature to get really
> solid. This is not a disparagement of anyone's coding skills or test
> coverage, that's just the reality. The problems that take a while to flush
> out can often be issues due to specific sites doing unexpected and strange
> things.
>
> Because we don't have a centralized release schedule for WebKit, that
> means there isn't necessarily a single window that is a good time for all
> vendors to take such a risk. That is why ifdefs are valuable even if a
> feature is ready to be on by default in testing builds like WebKit
> nightlies or Chromium canary channel.
>
> Regards,
> Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120502/28467426/attachment.html>