Re: [chromium-dev] Core Text

[Avi Drissman]

Even if there is a perf regression, we have to take it if we want to get
correct rendering.

Avi

On Mon, Dec 14, 2009 at 10:32 AM, Mike Pinkerton wrote:

> 2009/12/14 Jeremy Moskovich :
> > There should be no perf regression this time since we'll continue to use
> > ATSUI on 10.5 and only switch to Core Text on 10.6.2 [like Safari].
> > This should also have the effect of fixing [or modifying the stack
> traces]
> > we've been seeing for ATSUI crashes on 10.6.
>
> How do we know there won't be a perf regression on 10.6.2? We haven't
> measured it, so we may still be slowing things down, correct?
>
> --
> Mike Pinkerton
> Mac Weenie
> pinker...@google.com
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Extensions and the Mac

[Avi Drissman]

Right, but the rating average doesn't take that into account.

Avi

On Fri, Dec 11, 2009 at 12:59 PM, Dirk Pranke  wrote:

> If I'm running on Windows, I know to ignore the latter. That's a
> pretty big difference.
>
> -- Dirk
>
> On Fri, Dec 11, 2009 at 7:39 AM, Avi Drissman  wrote:
> > What the difference between:
> >
> > ★ this extension doesn't work at all wh
> >
> > and
> >
> > ★ As mentioned, this extension is incompatible with my Linux box. Bad
> > show. Bad show.
> >
> > Avi
> >
> > On Fri, Dec 11, 2009 at 10:29 AM, Mike Pinkerton 
> > wrote:
> >>
> >> One viewpoint I haven't seen mentioned on this thread is from that of
> >> the extension developer. Suppose they write, from their perspective, a
> >> perfectly good extension that uses binary components. After being
> >> around for a few weeks, they notice they have a 2-star rating and a
> >> lot of angry comments saying "this extension doesn't work at all
> >> wh"
> >>
> >> That doesn't really seem fair to the extension writer. People are
> >> complaining because they haven't been informed and we've not put a
> >> mechanism in place to inform them, and they take it out on the
> >> extension in terms of a really bad rating.
> >>
> >> On Fri, Dec 11, 2009 at 6:29 AM, PhistucK 
> wrote:
> >> > I believe the most elegant and quick (seemingly) solution is to
> provide
> >> > the
> >> > extension developers a field (in the extension gallery, not in the
> >> > extension
> >> > itself) that will include the platform and the version.
> >> > Going farther, you can add a check if the platform and the version (or
> >> > even
> >> > let the developer enter the search string) exist in the user agent or
> >> > anywhere else you can think of and show a warning next to the install
> >> > button.
> >> > And an automatic quick solution can be to go over the manifest (which
> >> > you
> >> > already do to search for NPAPI to add it to the approval queue) and
> see
> >> > if
> >> > there is a DLL, SO or whatever Macintosh is using in them. If there is
> a
> >> > DLL, add a "Compatible with the Windows platform" and so on, or the
> >> > opposite, if it does not contain, then you surely know - "Not
> compatible
> >> > with the Macintosh or Linux platforms".
> >> > ☆PhistucK
> >> >
> >> >
> >> > On Fri, Dec 11, 2009 at 03:54, Aaron Boodman  wrote:
> >> >>
> >> >> Yes, extensions that include NPAPI are a very small minority. Last
> >> >> time I checked there were something like 5. It is a way out for
> people
> >> >> who already have binary code that they would like to reuse, or who
> >> >> need to talk to the platform.
> >> >>
> >> >> I don't see what the big deal is about a few extensions only
> >> >> supporting a particular platform. As long as it is clear to users
> >> >> (you're right, we need to do this), I think this is ok.
> >> >>
> >> >> - a
> >> >>
> >> >> --
> >> >> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >> >> View archives, change email options, or unsubscribe:
> >> >>http://groups.google.com/group/chromium-dev
> >> >
> >> > --
> >> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> >> > View archives, change email options, or unsubscribe:
> >> > http://groups.google.com/group/chromium-dev
> >>
> >>
> >>
> >> --
> >> Mike Pinkerton
> >> Mac Weenie
> >> pinker...@google.com
> >
> > --
> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> > View archives, change email options, or unsubscribe:
> > http://groups.google.com/group/chromium-dev
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Extensions and the Mac

[Avi Drissman]

True...

It was noted earlier by James Robinson that a "properly written extension"
could detect and sniff the OS, and ensure that the correct binary was
loaded. But I never like pushing common work to the authors. If properly
handling "alternative platforms" (i.e. not Windows) involves work, guess the
percentage of authors not putting in the work.

Avi

On Fri, Dec 11, 2009 at 10:55 AM, Scott Hess  wrote:

> In one case, the user just wasted an hour and a half reinstalling
> various things and searching the interwebs trying to figure out what
> the problem is, so they're slightly more motivated to post than in the
> case where they've merely proved what the extension install page told
> them about compatibility.  Also, as a Linux user the second comment
> tells me something.
>
> [If the browser gave the user an error like "Are you crazy?  This
> extension is trying to load a library which couldn't possibly run on
> your OS", that would be great, but the extension referenced in the
> thread seems to install and run on Linux ... if a blank popup window
> is working, this is working swell!]
>
> -scott
>
>
> On Fri, Dec 11, 2009 at 7:39 AM, Avi Drissman  wrote:
> > What the difference between:
> >
> > ★ this extension doesn't work at all wh
> >
> > and
> >
> > ★ As mentioned, this extension is incompatible with my Linux box. Bad
> > show. Bad show.
> >
> > Avi
> >
> > On Fri, Dec 11, 2009 at 10:29 AM, Mike Pinkerton 
> > wrote:
> >>
> >> One viewpoint I haven't seen mentioned on this thread is from that of
> >> the extension developer. Suppose they write, from their perspective, a
> >> perfectly good extension that uses binary components. After being
> >> around for a few weeks, they notice they have a 2-star rating and a
> >> lot of angry comments saying "this extension doesn't work at all
> >> wh"
> >>
> >> That doesn't really seem fair to the extension writer. People are
> >> complaining because they haven't been informed and we've not put a
> >> mechanism in place to inform them, and they take it out on the
> >> extension in terms of a really bad rating.
> >>
> >> On Fri, Dec 11, 2009 at 6:29 AM, PhistucK 
> wrote:
> >> > I believe the most elegant and quick (seemingly) solution is to
> provide
> >> > the
> >> > extension developers a field (in the extension gallery, not in the
> >> > extension
> >> > itself) that will include the platform and the version.
> >> > Going farther, you can add a check if the platform and the version (or
> >> > even
> >> > let the developer enter the search string) exist in the user agent or
> >> > anywhere else you can think of and show a warning next to the install
> >> > button.
> >> > And an automatic quick solution can be to go over the manifest (which
> >> > you
> >> > already do to search for NPAPI to add it to the approval queue) and
> see
> >> > if
> >> > there is a DLL, SO or whatever Macintosh is using in them. If there is
> a
> >> > DLL, add a "Compatible with the Windows platform" and so on, or the
> >> > opposite, if it does not contain, then you surely know - "Not
> compatible
> >> > with the Macintosh or Linux platforms".
> >> > ☆PhistucK
> >> >
> >> >
> >> > On Fri, Dec 11, 2009 at 03:54, Aaron Boodman  wrote:
> >> >>
> >> >> Yes, extensions that include NPAPI are a very small minority. Last
> >> >> time I checked there were something like 5. It is a way out for
> people
> >> >> who already have binary code that they would like to reuse, or who
> >> >> need to talk to the platform.
> >> >>
> >> >> I don't see what the big deal is about a few extensions only
> >> >> supporting a particular platform. As long as it is clear to users
> >> >> (you're right, we need to do this), I think this is ok.
> >> >>
> >> >> - a
> >> >>
> >> >> --
> >> >> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >> >> View archives, change email options, or unsubscribe:
> >> >>http://groups.google.com/group/chromium-dev
> >> >
> >> > --
> >> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> >> > View archives, change email options, or unsubscribe:
> >> > http://groups.google.com/group/chromium-dev
> >>
> >>
> >>
> >> --
> >> Mike Pinkerton
> >> Mac Weenie
> >> pinker...@google.com
> >
> > --
> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> > View archives, change email options, or unsubscribe:
> > http://groups.google.com/group/chromium-dev
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Extensions and the Mac

[Avi Drissman]

What the difference between:

★ this extension doesn't work at all wh

and

★ As mentioned, this extension is incompatible with my Linux box. Bad
show. Bad show.

Avi

On Fri, Dec 11, 2009 at 10:29 AM, Mike Pinkerton wrote:

> One viewpoint I haven't seen mentioned on this thread is from that of
> the extension developer. Suppose they write, from their perspective, a
> perfectly good extension that uses binary components. After being
> around for a few weeks, they notice they have a 2-star rating and a
> lot of angry comments saying "this extension doesn't work at all
> wh"
>
> That doesn't really seem fair to the extension writer. People are
> complaining because they haven't been informed and we've not put a
> mechanism in place to inform them, and they take it out on the
> extension in terms of a really bad rating.
>
> On Fri, Dec 11, 2009 at 6:29 AM, PhistucK  wrote:
> > I believe the most elegant and quick (seemingly) solution is to provide
> the
> > extension developers a field (in the extension gallery, not in the
> extension
> > itself) that will include the platform and the version.
> > Going farther, you can add a check if the platform and the version (or
> even
> > let the developer enter the search string) exist in the user agent or
> > anywhere else you can think of and show a warning next to the install
> > button.
> > And an automatic quick solution can be to go over the manifest (which you
> > already do to search for NPAPI to add it to the approval queue) and see
> if
> > there is a DLL, SO or whatever Macintosh is using in them. If there is a
> > DLL, add a "Compatible with the Windows platform" and so on, or the
> > opposite, if it does not contain, then you surely know - "Not compatible
> > with the Macintosh or Linux platforms".
> > ☆PhistucK
> >
> >
> > On Fri, Dec 11, 2009 at 03:54, Aaron Boodman  wrote:
> >>
> >> Yes, extensions that include NPAPI are a very small minority. Last
> >> time I checked there were something like 5. It is a way out for people
> >> who already have binary code that they would like to reuse, or who
> >> need to talk to the platform.
> >>
> >> I don't see what the big deal is about a few extensions only
> >> supporting a particular platform. As long as it is clear to users
> >> (you're right, we need to do this), I think this is ok.
> >>
> >> - a
> >>
> >> --
> >> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >> View archives, change email options, or unsubscribe:
> >>http://groups.google.com/group/chromium-dev
> >
> > --
> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> > View archives, change email options, or unsubscribe:
> > http://groups.google.com/group/chromium-dev
>
>
>
> --
> Mike Pinkerton
> Mac Weenie
> pinker...@google.com
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Extensions and the Mac

[Avi Drissman]

We do? I didn't know that. Then we should enforce some kind of labeling.

Avi

On Thu, Dec 10, 2009 at 8:12 PM, Peter Kasting  wrote:

> On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman  wrote:
>
>> Q: Can't we have the extensions gallery warn that it won't work?
>> A: Sorry, we can't do that in an automated fashion. The extensions author
>> should mention it. Too bad they don't.
>>
>
> But we explicitly review patches with binary components.  I can't see how
> it could be impossible for us to also mark them as "Win-only".
>
> PK
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Extensions and the Mac

[Avi Drissman]

On Thu, Dec 10, 2009 at 8:00 PM, Ojan Vafai  wrote:

> I think we can wait to see what percentage of extensions actually include
> binaries before devoting too much time to this. Our expectation is that this
> will be a very small percentage, right?
>

If we give people the capabilities, people will use them. I see that we
would *like* for this to be a very small percentage, but I don't see why
that would cause it to be so.

Avi

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Extensions and the Mac

[Avi Drissman]

On Thu, Dec 10, 2009 at 7:55 PM, Ojan Vafai  wrote:

> I think we can wait to see what percentage of extensions actually include
> binaries before devoting too much time to this. Our expectation is that this
> will be a very small percentage, right?
>

Quick, look at
https://chrome.google.com/extensions/detail/pfhifmnkpieijjfdlmijncagohajdfmp.

Q: Can I install this on my Mac?
A: Sure, but it won't work, as it has an NPAPI dll.

Q: Can't we have the extensions gallery warn that it won't work?
A: Sorry, we can't do that in an automated fashion. The extensions author
should mention it. Too bad they don't.

Q: Can't we have the Chromium app warn that it won't work when it loads it?
A: Sorry, we can't do that in an automated fashion. The only notice that the
user will get when they have an extension that won't work on their platform
is that the extension malfunctions.

Avi

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Extensions and the Mac

[Avi Drissman]

On Thu, Dec 10, 2009 at 7:36 PM, Evan Martin  wrote:

> Distributing binaries on Linux = sadness, as the Flash guys will tell
> you.
> [...]
> In summary, all I offer you is more problems and the plea that we
> should really really deter people from doing this kind of thing.  I
> imagine a dystopian future where we have a per-extension appsupport
> matrix on the install page ("Works on x86-based ChromeOS but not
> arm-based ChromeOS" or whatever).
>

As much as I agree with everything you've said, I think the ship has already
sailed on this. We're already allowing binaries in extensions. Now we have
to figure out how to mitigate the pain.

Avi

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Extensions and the Mac

[Avi Drissman]

Is there a timetable? http://crbug.com/14936 has been Mstone-Xed since June.

Avi

On Thu, Dec 10, 2009 at 7:30 PM, Aaron Boodman  wrote:

> On Thu, Dec 10, 2009 at 4:27 PM, Avi Drissman  wrote:
> > Can we have the syntax say "platform x loads x.dll, platform y loads
> y.so,
> > etc"?
>
> Yes that is the idea.
>
> > If a dll required by a platform fails to load, we need to alert the user
> > that their extension is busted. The prospect of having failure to load
> > binaries be an expected thing scares me.
>
> Agree.
>
> - a
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Extensions and the Mac

[Avi Drissman]

Can we have the syntax say "platform x loads x.dll, platform y loads y.so,
etc"?

If a dll required by a platform fails to load, we need to alert the user
that their extension is busted. The prospect of having failure to load
binaries be an expected thing scares me.

Avi

On Thu, Dec 10, 2009 at 7:25 PM, Aaron Boodman  wrote:

> It is good that we can avoid the crash. We do need to get some kind of
> syntax in the manifest.
>
> - a
>
> On Thu, Dec 10, 2009 at 4:18 PM, Avi Drissman  wrote:
> > The crash is fixed. But the fact that we're now expecting random dll
> loads
> > to fail prevents us from giving good UI to users, and not labelling what
> > platforms it'll work on prevents us from warning in advance.
> >
> > Imagine a million angry Mac and Linux users filing bugs because their
> > favorite extension fails to fully load because it relies on an NPAPI
> plugin
> > not available on their platform.
> >
> > Avi
> >
> > On Thu, Dec 10, 2009 at 7:15 PM, Matt Perry 
> wrote:
> >>
> >> Yeah, that's very bad. I knew the NPAPI syntax sucked, but we punted on
> it
> >> because we didn't like any of the alternatives. (Even if we do have a
> >> manifest syntax for it, the extension package becomes bloated with
> plugin
> >> binaries for other platforms.) But I didn't realize that it could cause
> a
> >> crash. I'll definitely have to figure something out soon.
> >>
> >> On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman  wrote:
> >>>
> >>> Andy sent me a CL for review about an extension crashing
> >>> (http://crbug.com/29584). Turns out the cause was a failure to load a
> >>> Windows .dll on the Mac.
> >>>
> >>> Huh? Then I went to look at the docs
> >>> (http://code.google.com/chrome/extensions/npapi.html):
> >>>
> >>> {
> >>>   "name": "My extension",
> >>>   ...
> >>>   "plugins": [
> >>> { "path": "content_plugin.dll", "public": true },
> >>> { "path": "extension_plugin.dll" }
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>   ],
> >>>   ...
> >>> }
> >>>
> >>> Are you kidding me? How can we get away with not specifying what
> platform
> >>> the extension will run on? (Hint: we can't.)
> >>>
> >>> If we had something like:
> >>>
> >>> "plugins": {
> >>>   "mac": ...
> >>>   "win": ...
> >>>   "linux": ...
> >>> }
> >>>
> >>> then at least we could warn on the extensions website that a given
> >>> extension is only compatible with a certain platform. On a load attempt
> we
> >>> could know that the extension requires a certain native library and
> fail to
> >>> load it with a real user-friendly warning.
> >>>
> >>> And developers could make extensions that are cross-platform
> compatible.
> >>>
> >>> Today?
> >>> - We can't tell in advance what platforms an extensions runs on, so we
> >>> can't warn the user (either on the extensions site or in the app)
> >>> - The developer has no way of creating a cross-platform extension.
> >>>
> >>> This is a really bad situation we've created. We need to get a new
> syntax
> >>> out for extensions to fix this, and soon, before world-breaking becomes
> >>> prohibitively expensive.
> >>>
> >>> Avi
> >>>
> >>> --
> >>> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >>> View archives, change email options, or unsubscribe:
> >>> http://groups.google.com/group/chromium-dev
> >
> > --
> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> > View archives, change email options, or unsubscribe:
> > http://groups.google.com/group/chromium-dev
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Extensions and the Mac

[Avi Drissman]

The crash is fixed. But the fact that we're now expecting random dll loads
to fail prevents us from giving good UI to users, and not labelling what
platforms it'll work on prevents us from warning in advance.

Imagine a million angry Mac and Linux users filing bugs because their
favorite extension fails to fully load because it relies on an NPAPI plugin
not available on their platform.

Avi

On Thu, Dec 10, 2009 at 7:15 PM, Matt Perry  wrote:

> Yeah, that's very bad. I knew the NPAPI syntax sucked, but we punted on it
> because we didn't like any of the alternatives. (Even if we do have a
> manifest syntax for it, the extension package becomes bloated with plugin
> binaries for other platforms.) But I didn't realize that it could cause a
> crash. I'll definitely have to figure something out soon.
>
> On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman  wrote:
>
>>  Andy sent me a CL for review about an extension crashing (
>> http://crbug.com/29584). Turns out the cause was a failure to load a
>> Windows .dll on the Mac.
>>
>> Huh? Then I went to look at the docs (
>> http://code.google.com/chrome/extensions/npapi.html):
>>
>> {
>>   "name": "My extension",
>>   ...
>>   *"plugins": [
>> { "path": "content_plugin.dll", "public": true },
>> { "path": "extension_plugin.dll" }
>>
>>
>>
>>
>>   ]*,
>>   ...
>> }
>>
>> Are you kidding me? How can we get away with not specifying what platform
>> the extension will run on? (Hint: we can't.)
>>
>> If we had something like:
>>
>> "plugins": {
>>   "mac": ...
>>   "win": ...
>>   "linux": ...
>> }
>>
>> then at least we could warn on the extensions website that a given
>> extension is only compatible with a certain platform. On a load attempt we
>> could know that the extension requires a certain native library and fail to
>> load it with a real user-friendly warning.
>>
>> And developers could *make* extensions that are cross-platform
>> compatible.
>>
>> Today?
>> - We can't tell in advance what platforms an extensions runs on, so we
>> can't warn the user (either on the extensions site or in the app)
>> - The developer has no way of creating a cross-platform extension.
>>
>> This is a *really* bad situation we've created. We need to get a new
>> syntax out for extensions to fix this, and soon, before world-breaking
>> becomes prohibitively expensive.
>>
>> Avi
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/group/chromium-dev
>>
>
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Extensions and the Mac

[Avi Drissman]

http://codereview.chromium.org/492012

So the design is for every platform to try to load all plugins. We don't
even want to have a hint that allows the website to say "this is
Windows-only"?

How about from the browser perspective? Is failure to load a library a fatal
error? ("Sorry, we can't load this extension because it is damaged") Or is
it expected, since we're just likely hitting a library for a different
platform?

Avi

On Thu, Dec 10, 2009 at 7:12 PM, Aaron Boodman  wrote:

> On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman  wrote:
> > Andy sent me a CL for review about an extension crashing
> > (http://crbug.com/29584). Turns out the cause was a failure to load a
> > Windows .dll on the Mac.
>
> We have had threads on this before. The consensus was that it was
> possible to simply fail to load incompatible plugins, without
> crashing. That is, that it should be possible for each platform to try
> and load all plugins, but they will only succeed in loading those that
> are meant for them.
>
> Can you point me to the CL?
>
> - a
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Re: Extensions and the Mac

[Avi Drissman]

Filed http://code.google.com/p/chromium/issues/detail?id=30052 .

Avi

On Thu, Dec 10, 2009 at 7:03 PM, Avi Drissman  wrote:

> Andy sent me a CL for review about an extension crashing (
> http://crbug.com/29584). Turns out the cause was a failure to load a
> Windows .dll on the Mac.
>
> Huh? Then I went to look at the docs (
> http://code.google.com/chrome/extensions/npapi.html):
>
> {
>   "name": "My extension",
>   ...
>   *"plugins": [
> { "path": "content_plugin.dll", "public": true },
> { "path": "extension_plugin.dll" }
>
>
>   ]*,
>   ...
> }
>
> Are you kidding me? How can we get away with not specifying what platform
> the extension will run on? (Hint: we can't.)
>
> If we had something like:
>
> "plugins": {
>   "mac": ...
>   "win": ...
>   "linux": ...
> }
>
> then at least we could warn on the extensions website that a given
> extension is only compatible with a certain platform. On a load attempt we
> could know that the extension requires a certain native library and fail to
> load it with a real user-friendly warning.
>
> And developers could *make* extensions that are cross-platform compatible.
>
> Today?
> - We can't tell in advance what platforms an extensions runs on, so we
> can't warn the user (either on the extensions site or in the app)
> - The developer has no way of creating a cross-platform extension.
>
> This is a *really* bad situation we've created. We need to get a new
> syntax out for extensions to fix this, and soon, before world-breaking
> becomes prohibitively expensive.
>
> Avi
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Extensions and the Mac

[Avi Drissman]

Andy sent me a CL for review about an extension crashing (
http://crbug.com/29584). Turns out the cause was a failure to load a Windows
.dll on the Mac.

Huh? Then I went to look at the docs (
http://code.google.com/chrome/extensions/npapi.html):

{
  "name": "My extension",
  ...
  *"plugins": [
{ "path": "content_plugin.dll", "public": true },
{ "path": "extension_plugin.dll" }

  ]*,
  ...
}

Are you kidding me? How can we get away with not specifying what platform
the extension will run on? (Hint: we can't.)

If we had something like:

"plugins": {
  "mac": ...
  "win": ...
  "linux": ...
}

then at least we could warn on the extensions website that a given extension
is only compatible with a certain platform. On a load attempt we could know
that the extension requires a certain native library and fail to load it
with a real user-friendly warning.

And developers could *make* extensions that are cross-platform compatible.

Today?
- We can't tell in advance what platforms an extensions runs on, so we can't
warn the user (either on the extensions site or in the app)
- The developer has no way of creating a cross-platform extension.

This is a *really* bad situation we've created. We need to get a new syntax
out for extensions to fix this, and soon, before world-breaking becomes
prohibitively expensive.

Avi

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Download Manager and double notification on download complete

[Avi Drissman]

I'm working on some UI related to downloads, and I need a clean indication
that a download is finished. Not just finished but Finished. And I've found
we're getting two notifications: one before auto-opening happens, and one
after it happens.

If we look at DownloadManager::ContinueDownloadFinished (line 867) we see:

  // Notify our observers that we are complete (the call to Finished() set
> the
>   // state to complete but did not notify).
>   download->UpdateObservers();
>

That's at the very end, and that's the real Finished notification (auto-open
is done, etc). Looking at the comment we see that we'd called
DownloadItem::Finished earlier (in fact, in
DownloadManager::DownloadFinished, line 814). But if you look at the
implementation of DownloadItem::Finished you'll see that the comment is a
lie...

Glen changed it about a year
agoto
fix a bug, so I'm not keen on switching it back. But I need to know
when
a download's done. Any download experts have an opinion?

Avi

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Xcode, whitespace and you

[Avi Drissman]

On Mon, Nov 30, 2009 at 7:19 PM, Jens Alfke  wrote:

> second best would be a menu command
> to explicitly zap whitespace in the file being edited.


That's there. Select all, and then from the scripts menu > Google there's a
"fix whitespace" command.

Avi

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] CGAccessSessionSkipBytes

[Avi Drissman]

That showed up when I fixed a bug upstream by custom constructing a
CGDataProvider. It seems that internally when you do that, CG uses that
obsolete function. It's nothing we're doing directly.

Does it still do that for 10.6?

I can ask Apple.

Avi

On Thu, Nov 19, 2009 at 10:44 PM, Nico Weber  wrote:

> Hi,
>
> my new ToT chrome mac build logs this on the console:
>
> Thu Nov 19 22:39:53 thakis-macbookpro.local Chromium Helper[35086] :
> The function `CGAccessSessionSkipBytes' is obsolete and will be removed in
> an upcoming update. Unfortunately, this application, or a library it uses,
> is using this obsolete function, and is thereby contributing to an overall
> degradation of system performance. Please use `CGAccessSessionSkipForward'
> instead.
>
> I'm at r32597. Does that ring a bell for anyone?
>
> Nico
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Re: revert now, ask questions later? WAS: Reverting a change, the fast way

[Avi Drissman]

I'm OK with that.

Just make it clear that the sheriff does have authority. One time when I was
sheriff I wanted to revert a broken patch. The author insisted on patching
it over and over. He finally got it working about about seven patches and
nearly three hours or so, when I was insisting on backing it out after the
first 30m.

Avi

On Tue, Nov 3, 2009 at 5:34 PM, Peter Kasting  wrote:

> On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai  wrote:
>
>> To be clear, here's the proposed policy: Any change that would close the
>> tree can be reverted if it can't be fixed in <2 minutes.
>>
>
> How about:
>
> If a change closes the tree, the change author has 1 or 2 minutes to
> respond to a ping.  The change should be reverted if the author doesn't
> respond, if he says to revert, or if he does not say he has a fix within the
> next 5 minutes.
>
> I can't fix _any_ problem in 2 minutes.  But I can fix most of them in 5.
>  The goal is to allow the author a reasonable chance to fix trivial problems
> before we revert.  And I think the tree should go ahead and close during
> that interval.
>
> PK
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: HTML-as-UI CSS substitution

[Avi Drissman]

On Mon, Oct 26, 2009 at 5:44 PM, Evan Martin  wrote:

> Why not use sans-serif in the HTML, and then rely on the appropriate
> platform specific mapping of sans-serif -> font of choice in the
> WebKit prefs?
>

Good question. If the page is considered our UI then we would have an issue
with the user's fonts being used.

On Mon, Oct 26, 2009 at 5:44 PM, Glen Murphy  wrote:

> Why should these pages be treated any differently to any other
> webpage? i.e. what's wrong with font-family: Helvetica, Arial,
> sans-serif; - I'm pretty sure Windows users who have Helvetica
> installed won't mind too much, and it's not like these pages are meant
> to look native.
>

If this is an OK from the UX group to do that I don't have any problem doing
it either.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] HTML-as-UI CSS substitution

[Avi Drissman]

Many of our HTML files have CSS in them (about_credits.html,
about_memory.html, etc) which needs to be tweaked per-platform (more
specifically, using an appropriate sans-serif font; see
http://crbug.com/21458). We already do templating with jstemplate, but from
what I can tell it can't swap out the values of CSS selectors. Is the best
thing to do just to find/replace on the strings coming back from
ResourceBundle::GetRawDataResource?

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: External protocol dialog checkbox

[Avi Drissman]

On Tue, Oct 20, 2009 at 9:37 PM, Evan Stade  wrote:

>
> fyi: http://codereview.chromium.org/306017/show
>
>
Yes. As soon as that GRD change gets in I'm patching my code...

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: External protocol dialog checkbox

[Avi Drissman]

The latter in fact is how it's implemented on the Mac, though without the
renaming of the checkbox that would make it clear what's going on. I'd
support either version, and would alter my code to make it happen.

Avi

On Tue, Oct 20, 2009 at 4:01 PM, Evan Stade  wrote:

>
> There's a checkbox in the external protocol dialog with the text
> "Remember my choice for all links of this type." (On windows and
> linux, this is not actually implemented, but there are bugs out to fix
> that) The options are then "Cancel" and "Launch Application". The
> conflict here is that in general Cancel is supposed to not do
> anything, hence it can't honor the "Remember my choice for all links
> of this type" option. So that checkbox should either be renamed
> "Always allow this protocol", and not allow the user to always block
> that protocol, or the cancel button should be renamed to "don't launch
> app" or equivalent.
>
> -- Evan Stade
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] If changing a nib/xib file, please describe what you did, PLZ KTHX

[Avi Drissman]

I've seen many a CL containing changes to nib/xib files, and given that
those files are machine-generated XML, it's not immediately obvious what the
changes are. That's problematic for several reasons, two of which
immediately come to mind:

1. You can't adequately review the CL if you don't know what was done.
Inspection works for simple changes, but not for large ones.
2. Nib/xib file patches bitrot extremely quickly and hand-merging is
near-impossible. If a merge needs to happen (either someone else needs to
land the code, or perhaps you do), sometimes the easiest way to merge is to
just re-create the changes on the new ToT file, which is not possible if you
don't know what was done.

Thus my request. In any CL that changes a nib/xib file, can you please
provide a (brief) description of the change?

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Does Chromium MacOSX always create NSButtonCell for each html input submit button

[Avi Drissman]

Oh, and google.com has custom buttons which may or may not go through that
function at all (I haven't checked).

Avi

On Fri, Oct 9, 2009 at 4:44 PM, Avi Drissman  wrote:

> You found it.
>
> At the beginning of the function you see:
>
> *static* NSButtonCell *buttonCell;
>> //...
>> if (!buttonCell) {
>>
>
> There is only one cell created ever, and it's reused.
>
> Avi
>
>
> On Fri, Oct 9, 2009 at 4:20 PM, hap 497  wrote:
>
>>
>> Hi,
>>
>> Does Chromium MacOSX always create NSButtonCell for each html input
>> submit button?
>> I put a printf() statement in ThemeChromiumMac.mm:
>> static NSButtonCell* button(ControlPart part, ControlStates states,
>> const IntRect& zoomedRect, float zoomFactor).
>>
>> It gets called and create a NSButtonCell for a input submit button
>> when i load this test page:
>> 
>> 
>> 
>>
>> But when I load www.google.com (which has 2 input buttons), I don't
>> see the same button() function gets called to create NSButtonCell.
>>
>> Can you please tell me where is the code which create native gui
>> widget for input submit button for the case of www.google.com?
>>
>> Thank you.
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Does Chromium MacOSX always create NSButtonCell for each html input submit button

[Avi Drissman]

You found it.

At the beginning of the function you see:

*static* NSButtonCell *buttonCell;
> //...
> if (!buttonCell) {
>

There is only one cell created ever, and it's reused.

Avi

On Fri, Oct 9, 2009 at 4:20 PM, hap 497  wrote:

>
> Hi,
>
> Does Chromium MacOSX always create NSButtonCell for each html input
> submit button?
> I put a printf() statement in ThemeChromiumMac.mm:
> static NSButtonCell* button(ControlPart part, ControlStates states,
> const IntRect& zoomedRect, float zoomFactor).
>
> It gets called and create a NSButtonCell for a input submit button
> when i load this test page:
> 
> 
> 
>
> But when I load www.google.com (which has 2 input buttons), I don't
> see the same button() function gets called to create NSButtonCell.
>
> Can you please tell me where is the code which create native gui
> widget for input submit button for the case of www.google.com?
>
> Thank you.
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Converting dialogs to infobars

[Avi Drissman]

Will do first thing tomorrow.

Avi
/who figured it was OK since the string was already in the grd file

On Tue, Oct 6, 2009 at 6:25 PM, Ben Goodger (Google) wrote:

> Can you make sure a bug is filed to get this into the other platforms?
>
> -Ben
>
> On Tue, Oct 6, 2009 at 3:20 PM, Avi Drissman  wrote:
> > On Tue, Oct 6, 2009 at 6:18 PM, Glen Murphy  wrote:
> >>
> >> External protocol dialog should remain a dialog - I see it whenever I
> >> click on links to stuff in the iTunes store, and having it show as an
> >> infobar would be unpleasant.
> >
> > OT: Use the Mac version; you can set the "always allow this protocol"
> > checkbox.
> >
> > Avi
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Converting dialogs to infobars

[Avi Drissman]

On Tue, Oct 6, 2009 at 6:18 PM, Glen Murphy  wrote:

> External protocol dialog should remain a dialog - I see it whenever I
> click on links to stuff in the iTunes store, and having it show as an
> infobar would be unpleasant.
>

OT: Use the Mac version; you can set the "always allow this protocol"
checkbox.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Q about closing valgrind issues

[Avi Drissman]

So I got a reply from Apple saying this should be fixed in Snow Leopard. Is
it closable? Certainly keep it in the suppression list until we upgrade the
bots.

Avi

On Wed, Sep 23, 2009 at 12:46 AM, Erik Kay  wrote:

> I didn't say it would be easy. ;-)  I also wouldn't be surprised if
> window position varied across unit test runs.
>
> I think my main point here wasn't to drop everything you're doing to
> track this down.  I'm just saying that it's a dangerous bug to throw
> into the supression list and forget about.
>
> Erik
>
>
> On Tue, Sep 22, 2009 at 11:11 AM, Avi Drissman  wrote:
> > If this is caught in the unit tests ~1/30 times, then it's happening
> despite
> > the window positionings and view positionings being the same. There's
> > multiple layers of indirection in there (two context types, four
> libraries)
> > all totally closed source. Tracking it down feels like it would take way
> too
> > much effort and I'm swamped. If you have some spare time...
> >
> > Avi
> >
> > On Tue, Sep 22, 2009 at 11:56 AM, Erik Kay  wrote:
> >>
> >> I'd suspect an alignment / positioning bug for what you're seeing.
> >> Often rect fill algorithms have several paths with different loop
> >> unrolling tricks based on the size and position of the rect.  I agree
> >> with Evan that it may be worth tracking this down a bit more.  Even if
> >> it's not our bug, we need to find a way to avoid the memory stomping.
> >> I'm nervous about adding this to the upstream suppression list.  I
> >> think that's OK to do for memory leaks, or for memory errors where
> >> it's been demonstrated that the result of the error is benign (like
> >> the UMRs in parts of Microsoft's STL implementation), but it doesn't
> >> seem like this fits into that case.
> >>
> >> Erik
> >>
> >>
> >> On Mon, Sep 21, 2009 at 1:15 PM, Avi Drissman  wrote:
> >> > I have no evidence to confirm/deny that. Even so it deserves an
> >> > upstreaming.
> >> > I'll look at it but why would it show up 1/30 times?
> >> >
> >> > Avi
> >> >
> >> > On Mon, Sep 21, 2009 at 4:07 PM, Evan Martin 
> wrote:
> >> >>
> >> >> Could it possibly be related to passing a zero-sized rect in
> somewhere?
> >> >>
> >> >> On Mon, Sep 21, 2009 at 12:27 PM, Avi Drissman 
> wrote:
> >> >> > crbug.com/18189
> >> >> > crbug.com/18539
> >> >> >
> >> >> > I got the first because it involved the status bubble; I got the
> >> >> > second
> >> >> > because I got the first.
> >> >> >
> >> >> > NSRectFill(). Deep down that ends up in sseCGSFill8by1, which looks
> >> >> > like
> >> >> > it
> >> >> > sometimes scribbles off the end of some buffer. I have no idea what
> >> >> > we
> >> >> > could
> >> >> > be doing wrong to cause it nor what we could be doing to affect it
> at
> >> >> > all. I
> >> >> > want to just dup one to the other and mark both as
> >> >> > CANNOTFIXBADAPPLECODE^WWontFix. Any objections?
> >> >> >
> >> >> > Avi
> >> >> >
> >> >> > >
> >> >> >
> >> >
> >> >
> >> > > >> >
> >> >
> >
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] "FAIL" not catching image failures

[Avi Drissman]

Latest Mac pixel test result is here:
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5/builds/4420/steps/webkit_tests/logs/stdio
:

Regressions: Unexpected failures (2):
>   LayoutTests/svg/custom/js-late-marker-and-object-creation.svg = FAIL
>   LayoutTests/svg/hixie/error/012.xml = FAIL
>
> Those are both image mismatches, but are both accounted for in the
expectations file:

// Flaky. The width of containing RenderBlocks sometimes becomes larger
> BUG21958 WIN MAC LINUX DEBUG : LayoutTests/svg/hixie/error/012.xml = FAIL
> PASS
>

and

// Regressions from WebKit Merge 42932:42994
> BUG11239 MAC DEBUG :
> LayoutTests/svg/custom/js-late-marker-and-object-creation.svg = FAIL PASS
>

Why is the "FAIL" in those lines not catching the image failure?

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Turning on Mac pixel tests! Heads-up!

[Avi Drissman]

That didn't turn out so bad. Pixel tests turned on as of r27839. The first
batch had failures

http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5/builds/4417/steps/webkit_tests/logs/stdio

but the second one had just a timeout:

http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5%20%28dbg%29%281%29/builds/4845/steps/webkit_tests/logs/stdio

I think that'll do it. Let's let this run for a few cycles and throw flaky
tests into the expectations.

Avi


On Fri, Oct 2, 2009 at 9:52 AM, Avi Drissman  wrote:

> I'm turning on the Mac pixel tests today. There's two parts to this. First
> is the new expectations (http://codereview.chromium.org/249043) which just
> adds IMAGE failures and won't affect anything. The second is telling the
> bots to run the pixel tests (http://codereview.chromium.org/242099) and
> that might be an issue. If everything goes as planned, no one will notice.
> If things do not go as planned, the first build after the second checkin
> might fail with pixel issues. If that happens, blame me.
>
> Avi
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Turning on Mac pixel tests! Heads-up!

[Avi Drissman]

I'm turning on the Mac pixel tests today. There's two parts to this. First
is the new expectations (http://codereview.chromium.org/249043) which just
adds IMAGE failures and won't affect anything. The second is telling the
bots to run the pixel tests (http://codereview.chromium.org/242099) and that
might be an issue. If everything goes as planned, no one will notice. If
things do not go as planned, the first build after the second checkin might
fail with pixel issues. If that happens, blame me.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Shouldn't the Mac ignore the platform/win tests?

[Avi Drissman]

Right now I want to land so I'll file a bug...

Avi

On Thu, Oct 1, 2009 at 2:34 PM, Ojan Vafai  wrote:

> They are marked WONTFIX. We run them to ensure they don't crash. This looks
> like a bug in run_webkit_tests to me. For tests that are WONTFIX, we
> shouldn't care if the expected results are missing.
> Seems a bit silly to me that we run them at all though. I would be a fan of
> just skipping the platform tests that don't apply to the current platform.
> In practice, running them adds maintenance cost and cycle time (although,
> very little) but doesn't really catch crashes.
> Ojan
>
>
> On Thu, Oct 1, 2009 at 11:20 AM, Avi Drissman  wrote:
>
>> The output of a test run of the Mac pixel tests is at:
>>
>>
>> http://build.chromium.org/buildbot/try-server/builders/layout_mac/builds/85/steps/webkit_tests/logs/stdio
>>
>> What's weird is the line:
>>
>> Missing expected results (2):
>>   LayoutTests/fast/forms/menulist-style-color.html
>>   *LayoutTests/platform/win/accessibility/scroll-to-anchor.html*
>>
>> Why is it running a platform/win test? That's where the outputs are, and
>> not even the ones for the correct platform...
>>
>> Avi
>>
>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Shouldn't the Mac ignore the platform/win tests?

[Avi Drissman]

The output of a test run of the Mac pixel tests is at:

http://build.chromium.org/buildbot/try-server/builders/layout_mac/builds/85/steps/webkit_tests/logs/stdio

What's weird is the line:

Missing expected results (2):
  LayoutTests/fast/forms/menulist-style-color.html
  *LayoutTests/platform/win/accessibility/scroll-to-anchor.html*

Why is it running a platform/win test? That's where the outputs are, and not
even the ones for the correct platform...

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Getting pixel tests running on the Mac

[Avi Drissman]

Right--the question is for the long term if this will be a useful feature to
keep around or if we'll be dropping it once the Mac tests work. I'll take
the change either way but I can appreciate the extra granularity that this
would provide.

Pam:

> having a way to say "oh, it's 'only' the image that's bad" will increase
> maintenance burden and support ignoring problems.
>

We already have layout tests that deserve more attention than they get (thus
the LTTF). IMAGEFAIL tests are no less broken than TEXTFAIL, and if the
long-term aim is to not have *any* FAILs in the file anyway then I can see
real use in the granularity.

Avi

On Thu, Sep 24, 2009 at 3:15 PM, Amanda Walker  wrote:

> On Thu, Sep 24, 2009 at 3:11 PM, Ojan Vafai  wrote:
>
>> I don't think this is just about ignoring image-only results on mac for
>> the short-term. My subjective sense is that we have many tests that start
>> out as failing only image comparisons (e.g. due to theming), but over time
>> another failure creeps in that causes a text failure that goes unnoticed.
>> We'd ideally like to notice that extra regression when it happens as it
>> might be easy to identify and fix right at the time the regression occurs.
>>
>
> That's pretty much where we are with the Mac pixel tests--we do want to
> know if layout geometry regresses, even if there's a known pixel expectation
> failure (a color, or a missing spelling underline, or whatever it is for
> that test).
>
> --Amanda
>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Getting pixel tests running on the Mac

[Avi Drissman]

If you're already in there, go ahead.

Thanks,

Avi

On Wed, Sep 23, 2009 at 9:32 PM, Dirk Pranke  wrote:

> I think this plan sounds good, too.
>
> I'm mucking with those scripts a bit at the moment for the LTTF
> reporting, so I can make this change tomorrow, unless someone else
> would rather do it.
>
> I might actually prefer FAIL-TEXT and FAIL-IMAGE, but that's just me.
> I agree that TEXTFAIL is better than TEXT. Anyone else care to express
> a preference?
>
> -- Dirk
>
> On Wed, Sep 23, 2009 at 1:50 PM, Stephen White 
> wrote:
> > Could we make them TEXTFAIL and IMAGEFAIL, just to be clear?
> > Stephen
> >
> > (And then post them to failblog if they're really embarassing.. J/K ;)
> > On Wed, Sep 23, 2009 at 3:33 PM, Ojan Vafai  wrote:
> >>
> >> +pam, tc, darin in case they disagree with what I'm saying here.
> >>
> >> Also a bunch of current expectations would need to be modified. All
> >> the cases where there is currently FAIL would need to be changed to
> >> either FAIL or IMAGE or both if it's a text and image failure. You
> >> should be able to get most of the data for this by looking at the
> >> layout test dashboard. The only exception is you won't be able to
> >> distinguish tests that fail both image and text from tests that only
> >> fail image.
> >>
> >> A short-term solution could be to leave FAIL meaning IMAGE and/or TEXT
> >> and adding IMAGE and TEXT for image-only and text-only failures. Then
> >> we can gradually excise the FAIL lines from text_expectations.
> >>
> >> I think this would be a good permanent change, but I can see arguments
> >> to the contrary.
> >>
> >> Ojan
> >>
> >> On Wed, Sep 23, 2009 at 12:25 PM, Ojan Vafai  wrote:
> >> > There is not. But adding it would be easy. There's been mention of
> >> > doing this for a while, but noone has made the effort to make it work.
> >> > All you'd have to do is:
> >> > -modify a few lines in TestExpectationsFile in
> >> > src/webkit/tools/layout_tests/layout_package/test_expectations.py to
> >> > add support for IMAGE in test_expectations.
> >> > -treat IMAGE and other failures separately in
> >> > src/webkit/tools/layout_tests/layout_package/compare_failures.py.
> >> > Specifically, take test_failures.FailureImageHashMismatch out of
> >> > FAILURE_TYPES and add an IMAGE_FAILURE_TYPE and use it below.
> >> >
> >> > Ojan
> >> >
> >> > On Wed, Sep 23, 2009 at 12:16 PM, Avi Drissman 
> wrote:
> >> >> I've been looking into the pixel test situation on the Mac, and it
> >> >> isn't bad
> >> >> at all. Of ~5300 tests that have png results, we're failing ~800,
> most
> >> >> of
> >> >> which fall into huge buckets of easily-separable fail.
> >> >>
> >> >> Is there a way to specify that we're expecting an image compare to
> fail
> >> >> but
> >> >> still want the layout to succeed? We don't want to turn off the tests
> >> >> entirely while we fix them and run the chance of breaking something
> >> >> that
> >> >> layout would have caught.
> >> >>
> >> >> Avi
> >> >>
> >> >> >>
> >> >>
> >> >
> >>
> >>
> >
> >
> >
> > --
> > All truth passes through three stages. First, it is ridiculed. Second, it
> is
> > violently opposed. Third, it is accepted as being self-evident. --
> > Schopenhauer
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Getting pixel tests running on the Mac

[Avi Drissman]

BTW, would we want this to be temporary? I was thinking so, but then again,
being able to suppress a pixel failure separately from the layout failure
might be useful.

Avi

On Wed, Sep 23, 2009 at 3:24 PM, Avi Drissman  wrote:

> I'm new to the test runner (and to python in general). Can you give me a
> pointer where I should start?
>
> Avi
>
>
> On Wed, Sep 23, 2009 at 3:22 PM, Dirk Pranke  wrote:
>
>> No, there's no way to do that but it would be easy enough to add.
>>
>> -- Dirk
>>
>> On Wed, Sep 23, 2009 at 12:16 PM, Avi Drissman  wrote:
>> > I've been looking into the pixel test situation on the Mac, and it isn't
>> bad
>> > at all. Of ~5300 tests that have png results, we're failing ~800, most
>> of
>> > which fall into huge buckets of easily-separable fail.
>> >
>> > Is there a way to specify that we're expecting an image compare to fail
>> but
>> > still want the layout to succeed? We don't want to turn off the tests
>> > entirely while we fix them and run the chance of breaking something that
>> > layout would have caught.
>> >
>> > Avi
>> >
>> > >> >
>> >
>>
>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Getting pixel tests running on the Mac

[Avi Drissman]

I'm new to the test runner (and to python in general). Can you give me a
pointer where I should start?

Avi

On Wed, Sep 23, 2009 at 3:22 PM, Dirk Pranke  wrote:

> No, there's no way to do that but it would be easy enough to add.
>
> -- Dirk
>
> On Wed, Sep 23, 2009 at 12:16 PM, Avi Drissman  wrote:
> > I've been looking into the pixel test situation on the Mac, and it isn't
> bad
> > at all. Of ~5300 tests that have png results, we're failing ~800, most of
> > which fall into huge buckets of easily-separable fail.
> >
> > Is there a way to specify that we're expecting an image compare to fail
> but
> > still want the layout to succeed? We don't want to turn off the tests
> > entirely while we fix them and run the chance of breaking something that
> > layout would have caught.
> >
> > Avi
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Getting pixel tests running on the Mac

[Avi Drissman]

I've been looking into the pixel test situation on the Mac, and it isn't bad
at all. Of ~5300 tests that have png results, we're failing ~800, most of
which fall into huge buckets of easily-separable fail.

Is there a way to specify that we're expecting an image compare to fail but
still want the layout to succeed? We don't want to turn off the tests
entirely while we fix them and run the chance of breaking something that
layout would have caught.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Q about closing valgrind issues

[Avi Drissman]

It was in the suppression list already, just shifted around. The original
bug isn't closed; it's marked as upstream, though I don't know if that's a
significant difference :)

Feel free to play with it; I have some pixel tests to stare down.

Avi

On Wed, Sep 23, 2009 at 12:46 AM, Erik Kay  wrote:

> I didn't say it would be easy. ;-)  I also wouldn't be surprised if
> window position varied across unit test runs.
>
> I think my main point here wasn't to drop everything you're doing to
> track this down.  I'm just saying that it's a dangerous bug to throw
> into the supression list and forget about.
>
> Erik
>
>
> On Tue, Sep 22, 2009 at 11:11 AM, Avi Drissman  wrote:
> > If this is caught in the unit tests ~1/30 times, then it's happening
> despite
> > the window positionings and view positionings being the same. There's
> > multiple layers of indirection in there (two context types, four
> libraries)
> > all totally closed source. Tracking it down feels like it would take way
> too
> > much effort and I'm swamped. If you have some spare time...
> >
> > Avi
> >
> > On Tue, Sep 22, 2009 at 11:56 AM, Erik Kay  wrote:
> >>
> >> I'd suspect an alignment / positioning bug for what you're seeing.
> >> Often rect fill algorithms have several paths with different loop
> >> unrolling tricks based on the size and position of the rect.  I agree
> >> with Evan that it may be worth tracking this down a bit more.  Even if
> >> it's not our bug, we need to find a way to avoid the memory stomping.
> >> I'm nervous about adding this to the upstream suppression list.  I
> >> think that's OK to do for memory leaks, or for memory errors where
> >> it's been demonstrated that the result of the error is benign (like
> >> the UMRs in parts of Microsoft's STL implementation), but it doesn't
> >> seem like this fits into that case.
> >>
> >> Erik
> >>
> >>
> >> On Mon, Sep 21, 2009 at 1:15 PM, Avi Drissman  wrote:
> >> > I have no evidence to confirm/deny that. Even so it deserves an
> >> > upstreaming.
> >> > I'll look at it but why would it show up 1/30 times?
> >> >
> >> > Avi
> >> >
> >> > On Mon, Sep 21, 2009 at 4:07 PM, Evan Martin 
> wrote:
> >> >>
> >> >> Could it possibly be related to passing a zero-sized rect in
> somewhere?
> >> >>
> >> >> On Mon, Sep 21, 2009 at 12:27 PM, Avi Drissman 
> wrote:
> >> >> > crbug.com/18189
> >> >> > crbug.com/18539
> >> >> >
> >> >> > I got the first because it involved the status bubble; I got the
> >> >> > second
> >> >> > because I got the first.
> >> >> >
> >> >> > NSRectFill(). Deep down that ends up in sseCGSFill8by1, which looks
> >> >> > like
> >> >> > it
> >> >> > sometimes scribbles off the end of some buffer. I have no idea what
> >> >> > we
> >> >> > could
> >> >> > be doing wrong to cause it nor what we could be doing to affect it
> at
> >> >> > all. I
> >> >> > want to just dup one to the other and mark both as
> >> >> > CANNOTFIXBADAPPLECODE^WWontFix. Any objections?
> >> >> >
> >> >> > Avi
> >> >> >
> >> >> > >
> >> >> >
> >> >
> >> >
> >> > > >> >
> >> >
> >
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Q about closing valgrind issues

[Avi Drissman]

If this is caught in the unit tests ~1/30 times, then it's happening despite
the window positionings and view positionings being the same. There's
multiple layers of indirection in there (two context types, four libraries)
all totally closed source. Tracking it down feels like it would take way too
much effort and I'm swamped. If you have some spare time...

Avi

On Tue, Sep 22, 2009 at 11:56 AM, Erik Kay  wrote:

> I'd suspect an alignment / positioning bug for what you're seeing.
> Often rect fill algorithms have several paths with different loop
> unrolling tricks based on the size and position of the rect.  I agree
> with Evan that it may be worth tracking this down a bit more.  Even if
> it's not our bug, we need to find a way to avoid the memory stomping.
> I'm nervous about adding this to the upstream suppression list.  I
> think that's OK to do for memory leaks, or for memory errors where
> it's been demonstrated that the result of the error is benign (like
> the UMRs in parts of Microsoft's STL implementation), but it doesn't
> seem like this fits into that case.
>
> Erik
>
>
> On Mon, Sep 21, 2009 at 1:15 PM, Avi Drissman  wrote:
> > I have no evidence to confirm/deny that. Even so it deserves an
> upstreaming.
> > I'll look at it but why would it show up 1/30 times?
> >
> > Avi
> >
> > On Mon, Sep 21, 2009 at 4:07 PM, Evan Martin  wrote:
> >>
> >> Could it possibly be related to passing a zero-sized rect in somewhere?
> >>
> >> On Mon, Sep 21, 2009 at 12:27 PM, Avi Drissman  wrote:
> >> > crbug.com/18189
> >> > crbug.com/18539
> >> >
> >> > I got the first because it involved the status bubble; I got the
> second
> >> > because I got the first.
> >> >
> >> > NSRectFill(). Deep down that ends up in sseCGSFill8by1, which looks
> like
> >> > it
> >> > sometimes scribbles off the end of some buffer. I have no idea what we
> >> > could
> >> > be doing wrong to cause it nor what we could be doing to affect it at
> >> > all. I
> >> > want to just dup one to the other and mark both as
> >> > CANNOTFIXBADAPPLECODE^WWontFix. Any objections?
> >> >
> >> > Avi
> >> >
> >> > >
> >> >
> >
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Q about closing valgrind issues

[Avi Drissman]

I have no evidence to confirm/deny that. Even so it deserves an upstreaming.
I'll look at it but why would it show up 1/30 times?

Avi

On Mon, Sep 21, 2009 at 4:07 PM, Evan Martin  wrote:

> Could it possibly be related to passing a zero-sized rect in somewhere?
>
> On Mon, Sep 21, 2009 at 12:27 PM, Avi Drissman  wrote:
> > crbug.com/18189
> > crbug.com/18539
> >
> > I got the first because it involved the status bubble; I got the second
> > because I got the first.
> >
> > NSRectFill(). Deep down that ends up in sseCGSFill8by1, which looks like
> it
> > sometimes scribbles off the end of some buffer. I have no idea what we
> could
> > be doing wrong to cause it nor what we could be doing to affect it at
> all. I
> > want to just dup one to the other and mark both as
> > CANNOTFIXBADAPPLECODE^WWontFix. Any objections?
> >
> > Avi
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Q about closing valgrind issues

[Avi Drissman]

crbug.com/18189
crbug.com/18539

I got the first because it involved the status bubble; I got the second
because I got the first.

NSRectFill(). Deep down that ends up in sseCGSFill8by1, which looks like it
sometimes scribbles off the end of some buffer. I have no idea what we could
be doing wrong to cause it nor what we could be doing to affect it at all. I
want to just dup one to the other and mark both as
CANNOTFIXBADAPPLECODE^WWontFix. Any objections?

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Mac pixel tests: Why rebaselining is the only real option

[Avi Drissman]

Is that metrics for the layout rectangles or the pixels?

Avi

On Tue, Sep 8, 2009 at 2:57 PM, Evan Martin  wrote:

> On Tue, Sep 8, 2009 at 11:51 AM, Mark Mentovai wrote:
> > Avi Drissman wrote:
> >> Screw #2: The actual scrollbar is drawn just a wee bit shorter. Cocoa
> sizes
> >> scrollbar thumbs with a proportion value ([0..1]) while HITheme uses a
> >> "viewsize" value related to the physical size of the scrollbar. The
> precise
> >> formula Cocoa uses to turn the view size into its proportion value is
> >> unknown and would either have to be coaxed out of Apple or
> >> reverse-engineered. But even if you could fix both of these screws,
> you'd
> >> have to deal with...
> >
> > This all sounds reasonable to me.  I'd still like to know a little bit
> > more about "screw #2" because it seems like something that we should
> > understand a bit better before we decide to establish our own
> > baselines for these tests.
> >
> > I wonder what happens when the viewsize or one of the other parameters
> > is changed by ±15.  Maybe Cocoa is accounting for the "other"
> > scrollbar's presence or absence differently.
>
> Not saying you should do the same thing, but getting the font metrics
> on Linux to match Windows I recall agl and deanm spent a week or two
> going back and forth with "ok, if you add 0.82 * the baseline here it
> fixes these three fonts but that fourth one is still different".
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Mac pixel tests: Why rebaselining is the only real option

[Avi Drissman]

I was wrong in previous emails. All these scrollbars are the full 600
height, so I don't think the ±15 is the issue.

In any case, the documentation is utterly lacking as to what "viewsize"
means. Investigation would likely be punching in different values and seeing
what happens.

Avi

On Tue, Sep 8, 2009 at 2:51 PM, Mark Mentovai  wrote:

> Avi Drissman wrote:
> > Screw #2: The actual scrollbar is drawn just a wee bit shorter. Cocoa
> sizes
> > scrollbar thumbs with a proportion value ([0..1]) while HITheme uses a
> > "viewsize" value related to the physical size of the scrollbar. The
> precise
> > formula Cocoa uses to turn the view size into its proportion value is
> > unknown and would either have to be coaxed out of Apple or
> > reverse-engineered. But even if you could fix both of these screws, you'd
> > have to deal with...
>
> This all sounds reasonable to me.  I'd still like to know a little bit
> more about "screw #2" because it seems like something that we should
> understand a bit better before we decide to establish our own
> baselines for these tests.
>
> I wonder what happens when the viewsize or one of the other parameters
> is changed by ±15.  Maybe Cocoa is accounting for the "other"
> scrollbar's presence or absence differently.
>
> Mark
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Mac pixel tests: Why rebaselining is the only real option

[Avi Drissman]

As I discovered in code investigations on Friday and in emailing webkit-dev
today, when creating the master baseline pngs in the WebCore svn, the
containing scrollview is done with Cocoa.

This triply screws us. Take a look at the actual/expected scrollbars for
css1/basic/inheritance.html (sideways for space; expected on top):

[image: scroll.png]

Screw #1: The colors are off (actual is just slightly darker). Why? It could
be a ColorSync issue, or perhaps Cocoa draws scrollbars just a bit
differently than Carbon (HITheme) does. It probably wouldn't be too
difficult to discover why, but that's work that still leaves us with...

Screw #2: The actual scrollbar is drawn just a wee bit shorter. Cocoa sizes
scrollbar thumbs with a proportion value ([0..1]) while HITheme uses a
"viewsize" value related to the physical size of the scrollbar. The precise
formula Cocoa uses to turn the view size into its proportion value is
unknown and would either have to be coaxed out of Apple or
reverse-engineered. But even if you could fix both of these screws, you'd
have to deal with...

Screw #3: WebCore (as used in the baselines) only uses Cocoa scrollbars for
the containing scrollviews. Any interior scrollbars are drawn using
ScrollbarThemeMac (Carbon, HITheme, etc). (We use ScrollbarThemeMac for all
scrollbars.) So even if we were able to tweak ScrollbarThemeMac to draw
scrollbars to exactly match the Cocoa scrollbars, that would break them
matching all the internal ones.

The only conclusion I can reach is that rebaselining is the only sane option
here.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

<>

[chromium-dev] Re: Why scrollbars don't match on the Mac pixel tests

[Avi Drissman]

OK, here's a more interesting backtrace (bp on -[NSScroller
setKnobProportion:]:

#00x960957e1 in -[NSScroller setKnobProportion:]
#10x95fb0de3 in -[NSScrollView reflectScrolledClipView:]
#20x009a4aef in -[WebDynamicScrollBarsView(WebInternal)
reflectScrolledClipView:] at WebDynamicScrollBarsView.mm:211
#30x9607ef3a in -[NSClipView _reflectDocumentViewFrameChange]
#40x95f7a83d in -[NSView _postFrameChangeNotification]
#50x95f806e7 in -[NSView setFrameSize:]
#60x95f7693e in -[NSControl setFrameSize:]
#70x040d2e2c in WebCore::ScrollView::platformSetContentsSize at
ScrollViewMac.mm:136
#80x040cfae7 in WebCore::ScrollView::setContentsSize at
ScrollView.cpp:229
#90x03bc41a4 in WebCore::FrameView::setContentsSize at FrameView.cpp:356
#100x03bc244e in WebCore::FrameView::adjustViewSize at FrameView.cpp:376
#110x03bc63b5 in WebCore::FrameView::layout at FrameView.cpp:651

What happens is that in ScrollView::setContentsSize they take the
platformWidget() branch (see ScrollView.cpp:229). That lands them in
ScrollViewMac.mm and they get Cocoa all the way down.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Mac Chrome launch speed = the awesome

[Avi Drissman]

And on behalf of many of the other Mac folks, I have to thank Mark for
tearing into the problem and doing a lot of detective and coding work to
make it happen. He's incredible, and that's why we keep him working on
infrastructure work rather than actual Chromium coding; we don't want to
embarrass the other platforms by moving Chromium on the Mac too quickly. :)

Avi

On Tue, Sep 8, 2009 at 10:26 AM, Mark Mentovai  wrote:

>
> On behalf of the Mac folks, you're quite welcome!
>
> Mark
>
> Adam Barth wrote:
> > Thanks for making Mac Chrome launch ridiculously fast.  I really enjoy
> > that, on my laptop, the main window is painted before the dock icon
> > has even crested its first bounce.
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Why scrollbars don't match on the Mac pixel tests

[Avi Drissman]

Speculation here (while I'm not 100% convinced I'm 99.44% there), but...

Scrollbar thumb size has always been fuzzy. On the original Mac there was no
way to specify the thumb size, and even today HIThemeDrawTrack (which is the
most modern Mac theme-drawing API) has a parameter |viewsize| which is
under-specified. While the theory is to make

thumb : track :: view : doc size

the Mac scrollbar code passes in the page scroll size for the viewsize
parameter. You can see the code in ScrollbarThemeMac for details, but as an
example, for LayoutTests/css1/basic/inheritance.html, the WebCore Scrollbar
that had values visible size = 600, total size = 724 turned into:

scrollbar size: 15x585 (we lose 15px to the growbox)
min: 0
max: 124
viewsize: 560 (visible size of 600 - cAmountToKeepWhenPaging; see
ScrollView::updateScrollbars)

Now the scrollbar isn't 560/585 (96%) of the track so it's not clear where
the thumb size (as drawn) is coming from. But that's not the problem.

The problem is that I was trying to track down the same numbers for the
reference images so I could see where the metrics were diverging. And I
couldn't.

I got DumpRenderTree from WebCore loading in GDB, but breakpoints in
ScrollbarThemeMac.mm wouldn't hit. Nor would breakpoints in Scrollbar.cpp or
ScrollView.cpp. In desperation I breakpointed on HIThemeDrawTrack. And that
didn't hit either.

What *did* hit was -[NSScroller drawRect:] at this damning backtrace:

#00x96143759 in -[NSScroller drawRect:]
#10x9605fbf8 in -[NSView _drawRect:clip:]
#20x9605e6ef in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:]
#30x9605ea86 in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:]
#40x9605ea86 in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:]
#50x9605ea86 in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:]
#60x9605ea86 in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:]
#70x9605ea86 in -[NSView
_recursiveDisplayAllDirtyWithLockFocus:visRect:]
#80x9605d045 in -[NSView
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
#90x96145385 in -[NSNextStepFrame
_recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
#100x960594ab in -[NSView
_displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:]
#110x95f99e7b in -[NSView displayIfNeeded]
#120x00011ab4 in -[FrameLoadDelegate webView:didFinishLoadForFrame:] at
FrameLoadDelegate.mm:207

That's why the scrollbars are different. I thought that they'd moved from
using the Cocoa scroll code in WebCore, but it doesn't seem so.

Options:
1. Tweak ScrollbarThemeMac to generate values that make HIThemeDrawTrack
draw identically to Cocoa (or fork it; same diff)
2. Rebaseline all images that only involve scrollbar diffs without mercy.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Pixel tests on the Mac

[Avi Drissman]

Actively tracing through DumpRenderTree in WebCore. Getting layout info and
pixels that show I'm in the right file, and the png has scrollbars. But I
can't get gdb to break on ScrollbarThemeMac::paint and putting everything
from Debugger() to asm("int3") as the first statement in it isn't catching.
I suspect something's up. If this rings a bell, let me know.

Still investigating.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Pixel tests on the Mac

[Avi Drissman]

OK, that was due to a bad path. I have data from TestShell, and am trying to
catch DumpRenderTree as it draws the reference image. Again I'm getting a
blank image, but this time I have the path right.

Anyone have suggestions on WebCore?

Still investigating,

Avi

On Wed, Sep 2, 2009 at 3:09 PM, Avi Drissman  wrote:

> Aha! Thanks.
>
> Does anyone remember poking at scrollbars? I'm only hitting scrollbar code
> on the TestShell destructor, when we're loading about:blank to clear out
> WebCore. I'm getting some metric calculation calls but no painting...
>
> Still investigating,
>
> Avi
>
>
> On Mon, Aug 31, 2009 at 6:35 PM, John Grabowski  wrote:
>
>> Use --gdb with test shell.
>> jrg
>>
>> On Mon, Aug 31, 2009 at 2:38 PM, Avi Drissman  wrote:
>>
>>> Quite a few of those issues are now moot...
>>>
>>> Anyway, I'm trying to debug TestShell. I'm starting it with
>>> --testshell-startup-dialog, and attaching, but GDB never catches breakpoints
>>> and the shell dies before hitting anything. Has anyone dealt with this yet?
>>>
>>> Avi
>>>
>>>
>>> On Mon, Aug 31, 2009 at 5:15 PM, Thomas Van Lenten <
>>> thoma...@chromium.org> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Aug 31, 2009 at 5:01 PM, Avi Drissman  wrote:
>>>>
>>>>> OK, so I was looking at the result pngs, and I was wrong. It seems to
>>>>> be solely about the thumb length, which causes the wavy color to vary 
>>>>> along
>>>>> the length.
>>>>>
>>>>> Did we have any suspicions about how the length was turning out wrong
>>>>> the last time we looked at it?
>>>>>
>>>>>
>>>> I did not, I started crawling through the metrics/sizing code and
>>>> nothing had come up when I was doing it.
>>>>
>>>> http://dev.chromium.org/developers/browser-bootstrapping/mac-followup 
>>>> Lists what I found in getting the layout tests in to much better shape the
>>>> start of the year.  I think number 8 on the list has been fixed, but 4-7
>>>> might need to be checked again.
>>>>
>>>> I'm not sure if all these got converted into bugs by someone last time
>>>> someone looked at the list, it might be time to convert and nuke the page
>>>> once and for all (as long as the bugs are findable)  :)
>>>>
>>>> TVL
>>>>
>>>>
>>>>> Avi
>>>>>
>>>>> >>>>>
>>>>>
>>>>
>>>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Pixel tests on the Mac

[Avi Drissman]

Aha! Thanks.

Does anyone remember poking at scrollbars? I'm only hitting scrollbar code
on the TestShell destructor, when we're loading about:blank to clear out
WebCore. I'm getting some metric calculation calls but no painting...

Still investigating,

Avi

On Mon, Aug 31, 2009 at 6:35 PM, John Grabowski  wrote:

> Use --gdb with test shell.
> jrg
>
> On Mon, Aug 31, 2009 at 2:38 PM, Avi Drissman  wrote:
>
>> Quite a few of those issues are now moot...
>>
>> Anyway, I'm trying to debug TestShell. I'm starting it with
>> --testshell-startup-dialog, and attaching, but GDB never catches breakpoints
>> and the shell dies before hitting anything. Has anyone dealt with this yet?
>>
>> Avi
>>
>>
>> On Mon, Aug 31, 2009 at 5:15 PM, Thomas Van Lenten > > wrote:
>>
>>>
>>>
>>> On Mon, Aug 31, 2009 at 5:01 PM, Avi Drissman  wrote:
>>>
>>>> OK, so I was looking at the result pngs, and I was wrong. It seems to be
>>>> solely about the thumb length, which causes the wavy color to vary along 
>>>> the
>>>> length.
>>>>
>>>> Did we have any suspicions about how the length was turning out wrong
>>>> the last time we looked at it?
>>>>
>>>>
>>> I did not, I started crawling through the metrics/sizing code and nothing
>>> had come up when I was doing it.
>>>
>>> http://dev.chromium.org/developers/browser-bootstrapping/mac-followup Lists 
>>> what I found in getting the layout tests in to much better shape the
>>> start of the year.  I think number 8 on the list has been fixed, but 4-7
>>> might need to be checked again.
>>>
>>> I'm not sure if all these got converted into bugs by someone last time
>>> someone looked at the list, it might be time to convert and nuke the page
>>> once and for all (as long as the bugs are findable)  :)
>>>
>>> TVL
>>>
>>>
>>>> Avi
>>>>
>>>> >>>>
>>>>
>>>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Pixel tests on the Mac

[Avi Drissman]

Quite a few of those issues are now moot...

Anyway, I'm trying to debug TestShell. I'm starting it with
--testshell-startup-dialog, and attaching, but GDB never catches breakpoints
and the shell dies before hitting anything. Has anyone dealt with this yet?

Avi

On Mon, Aug 31, 2009 at 5:15 PM, Thomas Van Lenten wrote:

>
>
> On Mon, Aug 31, 2009 at 5:01 PM, Avi Drissman  wrote:
>
>> OK, so I was looking at the result pngs, and I was wrong. It seems to be
>> solely about the thumb length, which causes the wavy color to vary along the
>> length.
>>
>> Did we have any suspicions about how the length was turning out wrong the
>> last time we looked at it?
>>
>>
> I did not, I started crawling through the metrics/sizing code and nothing
> had come up when I was doing it.
>
> http://dev.chromium.org/developers/browser-bootstrapping/mac-followup Lists 
> what I found in getting the layout tests in to much better shape the
> start of the year.  I think number 8 on the list has been fixed, but 4-7
> might need to be checked again.
>
> I'm not sure if all these got converted into bugs by someone last time
> someone looked at the list, it might be time to convert and nuke the page
> once and for all (as long as the bugs are findable)  :)
>
> TVL
>
>
>> Avi
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Pixel tests on the Mac

[Avi Drissman]

OK, so I was looking at the result pngs, and I was wrong. It seems to be
solely about the thumb length, which causes the wavy color to vary along the
length.

Did we have any suspicions about how the length was turning out wrong the
last time we looked at it?

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Copying of profiles across systems

[Avi Drissman]

On Wed, Aug 26, 2009 at 2:31 PM, Ben Goodger (Google) wrote:

> Note that even upgrading Windows OS from XP to Vista involves changing
> paths:
>
> c:\Documents and Settings -> c:\Users
>
> Do we ever write paths such as this?
>

Yes.

>From my Preferences file on Windows:

 "id": "bfjgbcjfpbbfepcccpaffkjofcmglifg",
>  "images": {
> "theme_button_background": "C:\\Documents and
> Settings\\avi\\Local Settings\\Application Data\\Chromium\\User
> Data\\Default\\Extensions\\bfjgbcjfpbbfepcccpaffkjofcmglifg\\1.0\\i/agxjaHJvbWV0aGVtZXNyDAsSBEZpbGUY2rMBDA",
> "theme_frame": "C:\\Documents and Settings\\avi\\Local
> Settings\\Application Data\\Chromium\\User
> Data\\Default\\Extensions\\bfjgbcjfpbbfepcccpaffkjofcmglifg\\1.0\\i/agxjaHJvbWV0aGVtZXNyDAsSBEZpbGUYk6wBDA",
> "theme_ntp_background": "C:\\Documents and Settings\\avi\\Local
> Settings\\Application Data\\Chromium\\User
> Data\\Default\\Extensions\\bfjgbcjfpbbfepcccpaffkjofcmglifg\\1.0\\i/agxjaHJvbWV0aGVtZXNyDAsSBEZpbGUYzZwBDA",
> "theme_toolbar": "C:\\Documents and Settings\\avi\\Local
> Settings\\Application Data\\Chromium\\User
> Data\\Default\\Extensions\\bfjgbcjfpbbfepcccpaffkjofcmglifg\\1.0\\i/agxjaHJvbWV0aGVtZXNyDAsSBEZpbGUY2bMBDA"
>  },
>  "properties": {


This is from the themes section.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Copying of profiles across systems

[Avi Drissman]

Then password management would also fall under the category of "can't be
made portable" and that's fine.

It's just that I've heard "profile platform independence" tossed around as
being a guiding principle and I was surprised that some people treated it as
so.

Avi
/who wonders how it fits into
http://dev.chromium.org/developers/core-principles

On Wed, Aug 26, 2009 at 11:53 AM, Stuart Morgan
wrote:

> On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman wrote:
> > - Is "profile platform independence" a guiding principle?
> > [...]
> > - Is it worth rewriting today's code that doesn't conform
>
> It didn't seem to be when I asked about password storage a while back.
> Passwords aren't even portable from machine to machine--and I would be
> strongly opposed to making the password storage system platform
> agnostic, since it would mean abandoning an important piece of OS
> integration (including transparent password portability across
> browsers) on the Mac.
>
> That's not to say that we couldn't aim for making most of a profile
> portable, but I would be sad if we made a hard-and-fast rule that
> everything must be completely portable even at the cost of platform
> integration.
>
> -Stuart
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Copying of profiles across systems

[Avi Drissman]

I've heard people proclaim the principle of being able to copy a profile
across systems as being a deciding factor for certain changes (e.g. the
history epoch change). However, it doesn't seem to be universally held or
obeyed, and I'm not sure to the extent to which it can be obeyed. So some
questions:

- Is "profile platform independence" a guiding principle?
- To what extent do we work to make it reality?
- In the cases where it can't be kept (e.g. download folder path) should we
keep a copy for each platform?
- Is it worth rewriting today's code that doesn't conform (e.g. extensions
and themes which use full paths and platform path separators)?

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Mac History Menu

[Avi Drissman]

Brett—

Are we talking about the history page, or history items? The history page
gets its own tab, sure. But when someone picks an item from the history
menu, where does it go? I think current foreground tab is right, with
command for background tabs.

Avi

On Wed, Aug 12, 2009 at 3:14 PM, Brett Wilson  wrote:

>
> On Wed, Aug 12, 2009 at 11:15 AM, Robert Sesek wrote:
> > Two things about the Mac history menu that I'd like people to weigh in
> on:
> > 1. The "Show All History" command should have a keyboard shortcut. We
> can't
> > use the logical Cmd+H because it's bound by the system. Stuart suggested
> > Cmd+Y, as that's what Camino uses. Firefox and Safari both lack keyboard
> > shortcuts for this menu command, so it's really up to us to define it. So
> > Cmd+Y seems as good as any other. Thoughts?
> > 2. Currently, items in the history menu open in the current foreground
> tab.
> > I'm currently working on a CL to make it so that if you hold down the Cmd
> > modifier while selecting a history/bookmark menu item, it will open in a
> new
> > tab. I was wondering, though, if we should instead reverse this behavior
> so
> > that history items (and maybe bookmark?) open in a new tab, and you can
> use
> > the modifier to open in the current tab.
>
> Windows always opens history in a new tab. I think this is the correct
> behavior: I don't think anybody expects going to history will clobber
> their current tab.
>
> I don't see why there should be a modifier key to clobber the current
> tab. It seems obscure, useless, and potentially confusing.
>
> Brett
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Why does Chromium on mac have a theme switch UI in the preferences?

[Avi Drissman]

On Wed, Aug 12, 2009 at 9:41 AM, Meok  wrote:

> I guess it shouldn't be
> too hard then to pass that info onto the gallery page and keep
> everything online.


I think that would be a bad idea even if it weren't too hard. What theme I'm
using is no one's business.

When I was thinking about a "web page" I meant in the style of the NTP or
chrome://extensions, where the UI is done as HTML. I'm imagining in the
prefs dialog just one button: [Manage Themes] that took you to a theme
management page where you could show installed themes, switch between and
delete them, and it would have a link to the themes gallery.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Why does Chromium on mac have a theme switch UI in the preferences?

[Avi Drissman]

On Mon, Aug 10, 2009 at 1:31 PM, Aaron Boodman  wrote:

> > Incidentally, two other asks:
> > * When "installing" a theme, give the user a way to switch back to the
> > previous theme (e.g. an infobar).  We currently have an option to switch
> > back to the default theme, which is also useful, in different cases.
>
> We have a bug open on this. It requires some changes to the themes
> service. I think that Avi is working on this.
>

I am? Please assign the bug, then, because I was unaware of it.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Why does Chromium on mac have a theme switch UI in the preferences?

[Avi Drissman]

On Mon, Aug 10, 2009 at 7:46 AM, Mohamed Mansour  wrote:

> I have been told that once you installed a new theme, the old theme will
> not be archived (stored on the system), so switching themes would be harder
> when the CL comes in.
>

That isn't the case today; that may be the case in the future.


> I thought you guys are picky when it comes to options
>

This one's mine, so I'll take the blame/praise as it goes.

Right now there's no real control over themes. Once they're installed,
they're permanently installed; there's no easy way to remove them
(chrome://extensions used to list them so they could be removed, but now you
can't even do that). So why not let the user switch?

Assuming that the themes gallery will be the only source of themes and that
the users would just have to go there is silly. The "Get Themes" button is
only a suggestion, and while we have themes that we think are nice, there
will be third-party providers.

If you don't think the popup does an adequate job of showing
previews/management, you are absolutely correct. I'd love a chrome://themes
page that
- showed installed themes
-- with previews
-- with deinstall buttons
- allowed switching themes
- allowed tinting for themes (which I've heard only Cole talk about but no
one else mention)

Until then I figured that throwing a picker into prefs would be something
useful.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design Doc: out of process (v8) proxy resolving

[Avi Drissman]

As an aside, favicons are handled in the renderer, sandboxed. The renderer
decodes them and reencodes them as PNG to ensure that they're safe before
handing them off to the browser process. Trace the ViewMsg_DownloadFavIcon,
ViewHostMsg_UpdateFavIconURL, and ViewHostMsg_DidDownloadFavIcon messages
for more detail.

Avi

On Wed, Jul 29, 2009 at 12:00 PM, Avi Drissman  wrote:

> On Wed, Jul 29, 2009 at 11:52 AM, Mike Pinkerton 
> wrote:
>
>> Don't we farm out a separate process for favicon decoding? And for
>> theme image decoding as well?
>
>
> There are two things done by the utility process. Unpacking of themes (not
> just images but the unzipping of the packages, parsing of the JSON, and
> unpacking the images) and unpacking of "web resources". That's
> WebResourceService, which seems right now to be used for the external "tips
> list".
>
> Favicons do not appear to be handled by the utility process.
>
> Avi
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design Doc: out of process (v8) proxy resolving

[Avi Drissman]

On Wed, Jul 29, 2009 at 11:52 AM, Mike Pinkerton wrote:

> Don't we farm out a separate process for favicon decoding? And for
> theme image decoding as well?


There are two things done by the utility process. Unpacking of themes (not
just images but the unzipping of the packages, parsing of the JSON, and
unpacking the images) and unpacking of "web resources". That's
WebResourceService, which seems right now to be used for the external "tips
list".

Favicons do not appear to be handled by the utility process.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Layout test failures from WebKit merge 45873:45916

[Avi Drissman]

http://code.google.com/p/chromium/issues/detail?id=17015 was the layout
failures from a merge, and I got assigned them because I'd checked in a
small Mac-only change. Turns out that many of them are due to the failure to
red-dotted-underline misspelled words and slight differences in the
selection glow. Anyone hear about a change upstream that would cause
something like that? Eyeballing the relevant changes in the WebKit SVN
server doesn't yield anything that would look like it would do that.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Themes and their removal

[Avi Drissman]

Ahh... So there needs to be a reset button in prefs. I can look it up, but
does it just uninstall all theme extensions?

Deleting a theme from the extensions page does leave stuff behind.

Avi

On Wed, Jul 15, 2009 at 12:03 PM, Glen Murphy  wrote:

> There is no theme management - there is a 'reset to default' button in
> options, and that's it. 'Management' is done by using the themes site
> and reinstalling from there. Users should never see the word
> 'extension' if all they care about is themes, at least for 3.0.
>
>
>
> On Wed, Jul 15, 2009 at 8:15 AM, Avi Drissman wrote:
> > On Wed, Jul 15, 2009 at 11:09 AM, Erik Kay  wrote:
> >>
> >> On Wed, Jul 15, 2009 at 7:44 AM, Avi Drissman  wrote:
> >>>
> >>> First, you said that you were going to make it so that when you install
> >>> one theme it uninstalls all others. Is that coming soon?
> >>
> >> I don't know if that's the case.  I believe the intention is that the
> >> theme stays installed, but simply that the app switches to use the new
> >> theme.  Is this right Glen?
> >
> > So the old theme sits around unused. What happens when we uninstall the
> > current theme? Do we reinstall the older theme? Which older theme?
> >
> >>
> >> I assume you're talking about uninstalling the theme from
> >> chrome://extensions.
> >
> > Is there a different way to uninstall a theme?
> >
> >>
> >> On the other hand, I think Glen would prefer that we not show themes at
> >> all on chrome://extensions, which would reduce the need for this
> altogether
> >> (although it may still be a good idea for correctness).  What do you
> think
> >> Glen?
> >
> > I think that themes might be technically extensions, but that they should
> be
> > treated differently as they have different semantics than normal crxen
> (only
> > one active at once, etc). We should have a list of "installed themes" so
> the
> > user can switch between them.
> >
> >>
> >> I'd file a bug for the second, but punt on the first.
> >
> > Well, if I can find the cause for the second, I'll just fix it...
> >
> > Avi
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Themes and their removal

[Avi Drissman]

On Wed, Jul 15, 2009 at 11:09 AM, Erik Kay  wrote:

> On Wed, Jul 15, 2009 at 7:44 AM, Avi Drissman  wrote:
>
>> First, you said that you were going to make it so that when you install
>> one theme it uninstalls all others. Is that coming soon?
>
>
> I don't know if that's the case.  I believe the intention is that the theme
> stays installed, but simply that the app switches to use the new theme.  Is
> this right Glen?
>

So the old theme sits around unused. What happens when we uninstall the
current theme? Do we reinstall the older theme? Which older theme?


> I assume you're talking about uninstalling the theme from
> chrome://extensions.
>

Is there a different way to uninstall a theme?


> On the other hand, I think Glen would prefer that we not show themes at all
> on chrome://extensions, which would reduce the need for this altogether
> (although it may still be a good idea for correctness).  What do you think
> Glen?
>

I think that themes might be technically extensions, but that they should be
treated differently as they have different semantics than normal crxen (only
one active at once, etc). We should have a list of "installed themes" so the
user can switch between them.


> I'd file a bug for the second, but punt on the first.
>

Well, if I can find the cause for the second, I'll just fix it...

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Themes and their removal

[Avi Drissman]

I'm playing around fixing the rough edges of the Mac theme implementation
and I'm hitting areas where it doesn't seem to be implemented for any
platform.

First, you said that you were going to make it so that when you install one
theme it uninstalls all others. Is that coming soon?

I ask because I'm running into the issue where uninstalling a theme (when
it's the only one left) pulls out the images but leaves residue in the
Preferences. The bitmap in the window doesn't go away on the uninstall (and
no "theme change" notification fires), and on restart of the browser I get
remnants of the color scheme. I'd change the code, but I don't know how that
would interact with having a second theme sitting around unused (thus the
first question).

How do we want to go with this?

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Theme re-encoding

[Avi Drissman]

PNG is lossless, so we should be good there.

Avi

On Fri, Jul 10, 2009 at 4:30 PM, Aaron Boodman  wrote:

> On this same subject -- do we do any lossy compression in our png
> encoding? I think we should *not*. Developers will be peeved if their
> carefully compressed images come out looking different because of our
> internal implementation details.
>
> - a
>
> On Fri, Jul 10, 2009 at 1:17 PM, Avi Drissman wrote:
> > Nailed: http://codereview.chromium.org/149473
> >
> > Avi
> >
> > On Fri, Jul 10, 2009 at 4:15 PM, Amanda Walker 
> wrote:
> >>
> >> On Fri, Jul 10, 2009 at 3:54 PM, Avi Drissman wrote:
> >> > Two things. First, this doesn't happen on Windows. Second, how do you
> >> > get an
> >> > image shifted one pixel to the right? On the Mac, ImageDecoder::Decode
> >> > uses
> >> > the webkit decoders which on the Mac return a CGImage, and then
> >> > gfx::CGImageToSkBitmap is called.
> >>
> >> Well, all platforms use the webkit decoders (as of Darin's refactoring
> >> in January), they just return different the image differently.
> >> gfx::CGImageToSkBitmap does sound like a likely culprit, though :-).
> >>
> >> --Amanda
> >
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Theme re-encoding

[Avi Drissman]

Nailed: http://codereview.chromium.org/149473

Avi

On Fri, Jul 10, 2009 at 4:15 PM, Amanda Walker  wrote:

> On Fri, Jul 10, 2009 at 3:54 PM, Avi Drissman wrote:
> > Two things. First, this doesn't happen on Windows. Second, how do you get
> an
> > image shifted one pixel to the right? On the Mac, ImageDecoder::Decode
> uses
> > the webkit decoders which on the Mac return a CGImage, and then
> > gfx::CGImageToSkBitmap is called.
>
> Well, all platforms use the webkit decoders (as of Darin's refactoring
> in January), they just return different the image differently.
> gfx::CGImageToSkBitmap does sound like a likely culprit, though :-).
>
> --Amanda
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Theme re-encoding

[Avi Drissman]

A...

Two things. First, this doesn't happen on Windows. Second, how do you get an
image shifted one pixel to the right? On the Mac, ImageDecoder::Decode uses
the webkit decoders which on the Mac return a CGImage, and then
gfx::CGImageToSkBitmap is called.

I'm going to go over gfx::CGImageToSkBitmap carefully. It does the
conversion by drawing the image into the bitmap...

Avi

On Fri, Jul 10, 2009 at 3:38 PM, Avi Drissman  wrote:

> Even with a jpg source we get column 0 invisible, so it's a PNG encoder
> issue. In addition, in an imaged editor it looks like the image is shifted
> over one pixel, not that the first column was overwritten.
>
> Avi
>
>
> On Fri, Jul 10, 2009 at 12:21 PM, Avi Drissman  wrote:
>
>> I'm building an extension with a jpg source. If it gets the column then
>> it's an encoder issue, else decoder issue. I'll let you know as soon as I
>> find out.
>>
>> Avi
>>
>>
>> On Fri, Jul 10, 2009 at 12:18 PM, Glen Murphy  wrote:
>>
>>> This may be a PNGEncoder/Decoder bounce issue, and I don't think the
>>> base gfx unittests check the first vertical column of pixels.
>>>
>>> I landed some changes to PNGEncoder/Decoder in the last week, but it
>>> seems like the problem existed before then. Not sure whether the issue
>>> is that the first column gets corrupted, or whether everything gets
>>> right-shifted by one. I suspect the former, as our favicons go through
>>> this bounce process and we'd probably have noticed clipping there.
>>>
>>>
>>> On Fri, Jul 10, 2009 at 9:04 AM, Avi Drissman wrote:
>>> > We re-encode the pngs in themes. Somewhere in the the process we break
>>> them;
>>> > we're encoding them off by one pixel, so that we have a vertical line
>>> on the
>>> > left, one pixel wide, that's transparent. It isn't obvious on Windows
>>> (but
>>> > it is there; look for it!) but it's glaringly obvious on the Mac. I'm
>>> going
>>> > to look at it after I land the first pass at theming today, but can you
>>> > think of an obvious cause?
>>> >
>>> > Avi
>>> >
>>> > >>> >
>>> >
>>>
>>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Theme re-encoding

[Avi Drissman]

Even with a jpg source we get column 0 invisible, so it's a PNG encoder
issue. In addition, in an imaged editor it looks like the image is shifted
over one pixel, not that the first column was overwritten.

Avi

On Fri, Jul 10, 2009 at 12:21 PM, Avi Drissman  wrote:

> I'm building an extension with a jpg source. If it gets the column then
> it's an encoder issue, else decoder issue. I'll let you know as soon as I
> find out.
>
> Avi
>
>
> On Fri, Jul 10, 2009 at 12:18 PM, Glen Murphy  wrote:
>
>> This may be a PNGEncoder/Decoder bounce issue, and I don't think the
>> base gfx unittests check the first vertical column of pixels.
>>
>> I landed some changes to PNGEncoder/Decoder in the last week, but it
>> seems like the problem existed before then. Not sure whether the issue
>> is that the first column gets corrupted, or whether everything gets
>> right-shifted by one. I suspect the former, as our favicons go through
>> this bounce process and we'd probably have noticed clipping there.
>>
>>
>> On Fri, Jul 10, 2009 at 9:04 AM, Avi Drissman wrote:
>> > We re-encode the pngs in themes. Somewhere in the the process we break
>> them;
>> > we're encoding them off by one pixel, so that we have a vertical line on
>> the
>> > left, one pixel wide, that's transparent. It isn't obvious on Windows
>> (but
>> > it is there; look for it!) but it's glaringly obvious on the Mac. I'm
>> going
>> > to look at it after I land the first pass at theming today, but can you
>> > think of an obvious cause?
>> >
>> > Avi
>> >
>> > >> >
>> >
>>
>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Theme re-encoding

[Avi Drissman]

I'm building an extension with a jpg source. If it gets the column then it's
an encoder issue, else decoder issue. I'll let you know as soon as I find
out.

Avi

On Fri, Jul 10, 2009 at 12:18 PM, Glen Murphy  wrote:

> This may be a PNGEncoder/Decoder bounce issue, and I don't think the
> base gfx unittests check the first vertical column of pixels.
>
> I landed some changes to PNGEncoder/Decoder in the last week, but it
> seems like the problem existed before then. Not sure whether the issue
> is that the first column gets corrupted, or whether everything gets
> right-shifted by one. I suspect the former, as our favicons go through
> this bounce process and we'd probably have noticed clipping there.
>
>
> On Fri, Jul 10, 2009 at 9:04 AM, Avi Drissman wrote:
> > We re-encode the pngs in themes. Somewhere in the the process we break
> them;
> > we're encoding them off by one pixel, so that we have a vertical line on
> the
> > left, one pixel wide, that's transparent. It isn't obvious on Windows
> (but
> > it is there; look for it!) but it's glaringly obvious on the Mac. I'm
> going
> > to look at it after I land the first pass at theming today, but can you
> > think of an obvious cause?
> >
> > Avi
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Theme re-encoding

[Avi Drissman]

We re-encode the pngs in themes. Somewhere in the the process we break them;
we're encoding them off by one pixel, so that we have a vertical line on the
left, one pixel wide, that's transparent. It isn't obvious on Windows (but
it is there; look for it!) but it's glaringly obvious on the Mac. I'm going
to look at it after I land the first pass at theming today, but can you
think of an obvious cause?

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Running Cocoa in the renderer and bug 14609

[Avi Drissman]

Core Graphics is a level lower than Cocoa, and as the main way to draw on
the Mac would be OK to use. I don't know what we use Cocoa for. I think
widget rendering but I could be wrong.

Avi

On Fri, Jun 19, 2009 at 10:58 AM, Evan Martin  wrote:

> On Fri, Jun 19, 2009 at 6:44 AM, Avi Drissman wrote:
> > In the long term, I think this is yet another reminder about getting
> Cocoa
> > out of the renderer... :)
>
> What do you use Cocoa in the renderer for?
> Does that include Core Graphics?
> Or is it just for widget rendering?
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Running Cocoa in the renderer and bug 14609

[Avi Drissman]

http://crbug.com/14609 ...

In the renderer we need to run Cocoa on a non-main thread. To pump
windowserver events we need to pump on the main thread. And when we do so
timers and notifications fire, screwing us over. I think the timers and
notifications were not fired before, right?

In the short term, I think that changing the run loop mode in which we pull
events should fix things. I'm trying that out now.

In the long term, I think this is yet another reminder about getting Cocoa
out of the renderer... :)

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Fixing our keyboard handling act on OSX

[Avi Drissman]

Very interesting writeup. Some thoughts:

You don't touch on how Safari on the Mac handles this case. It seems to
overlap with some of the work that Jeremy was doing based on his discoveries
in WebKit's WebHTMLView.mm. Where does its _interceptEditingKeyEvent get
called?

Synthesizing CHAR events is an interesting idea, but how would that interact
with the WebCore's handling of events? In particular, how would it interact
with the fact that WebCore also synthesizes CHAR events in
disambiguateKeyDown()?

Avi

2009/6/5 Hironori Bono (坊野 博典) 

> Hi Jeremy, et al,
>
> Sorry for my slow update.
> This is the draft report of my investigation that implements the
> NSTextInput protocol on Mac, implements the GtkIMContext on Linux and
> observes keyboard events on Windows, Mac, and Linux. (Sorry, I would
> like to send it as a PDF file because the google site somehow
> compresses its figures too much to make its characters unreadable.)
> Since I'm still finding the best solutions for the issues, any
> comments and suggestions are definitely welcome.
>
> Regards,
>
> Hironori Bono
> E-mail: hb...@chromium.org
>
> 2009/5/29 Hironori Bono (坊野 博典) :
> > Hi Jeremy,
> >
> > I have been investigating keyboard events on Windows, Linux, and Mac
> > to find solutions for these issues. Shall we have a discussion about
> > these issues when I finish writing my report (maybe sometime next
> > week)?
> >
> > Regards,
> >
> > Hironori Bono
> > E-mail: hb...@chromium.org
> >
> > On Thu, May 28, 2009 at 7:14 AM, Jeremy Moskovich 
> wrote:
> >> Hi All,
> >> We currently fudge our keyboard handling on OSX, we interpret command
> key
> >> shortcuts ourselves and thus miss out on quite a few Cocoa text handling
> >> niceities.  We also don't support IMEs.
> >> Relevant bugs:
> >> http://crbug.com/10862 - OS X: Can't use command-key shortcuts with
> foreign
> >> keyboard layouts
> >> http://crbug.com/12698 - standard macintosh text editing keyboard
> shortcuts
> >> are missing
> >> http://crbug.com/11981 - Deadkeys do not work
> >> http://crbug.com/11952 - IME support (Chinese input method doesnt work)
> >> We also don't handle activation/deactivation of edit menu items
> correctly
> >> (select all is always disabled).
> >> I've done a little digging in WebKit's keyboard handling and what
> follows is
> >> a proposal on how we can more closely match the OSX keyboard handling
> code
> >> and [hopefully] do things the right way.  I don't purport to understand
> this
> >> all and there may be simpler ways to achieve this so feel free to
> comment.
> >> Standard commands (Copy/Paste/Select-all):
> >> WebKit handles these through the regular obj-c selectors in WebHTMLView,
> see
> >> the WEBCORE_COMMAND macro.
> >> We could do the same thing and add these selectors
> >> to BrowserWindowController which would then send an IPC message over to
> the
> >> renderer process to execute the appropriate command.
> >> The tricky bit is updating the menus, the model in Cocoa is for the OS
> to
> >> call you for each menu item before displaying a menu.  We can't block
> the
> >> browser process on the renderer process so the browser process would
> always
> >> need to know if there is an active selection.  WebCore appears to
> already
> >> have a mechanism to do this via notifyAccessibilityForSelectionChange()
> - we
> >> could use the same or a similar mechanism to send an IPC message back to
> the
> >> browser process each time the selection changes.
> >> Emacs keyboard commands and IMEs:
> >> The IME part of the title may be nonsense, but looking at the code it
> >> appears the code path and issues are the same.
> >> I've attached the stack trace for hitting cntrl-t to the end of this
> email.
> >>  The tricky bit here is that WebCore is first given a shot at handling
> the
> >> event and then passes it back to WebHTMLView to take another look at the
> >> event which is where it's actually parsed.  I assume this is to give JS
> code
> >> a chance to listen on these events.
> >> Since we can't serialize an NSEvent, we can't replicate this code solely
> in
> >> the renderer.
> >> A possible solution to this would be to store a queue of the last N
> NSEvents
> >> per renderer matched with an ID.  the event would then be serialized and
> >> sent to the renderer which could then send it's own IPC message back to
> the
> >> browser process to get Cocoa to handle the message, we could pick the
> >> NSEvent out of the queue by ID and send back the relevant edit command
> to
> >> the renderer.
> >> Since the events belong to a specific renderer a malicious renderer
> process
> >> can't access events not targeted at them.
> >> Best regards,
> >> Jeremy
> >> Stack trace of hitting cntrl-t (transpose) in a text view, Cocoa
> >> [browser-process] stuff marked in bold.
> >> #0 WebCore::executeTranspose (frame=0x70b9800) at
> >>
> /Users/Shared/playmobil/work/git.WebKit/WebCore/editing/EditorCommand.cpp:961
> >> #1 0x03702f0f in WebCore::Editor::Command::execute (t

[chromium-dev] Re: message between renderer and browser

[Avi Drissman]

There is one message for forwarding any type of input event. Trace backwards
and forwards from RenderWidgetHost::ForwardInputEvent().

Avi

On Tue, Jun 2, 2009 at 3:48 PM, meryl  wrote:

>
> Hi,
>
> I am reading the messaging between renderer and browser:
>
> http://dev.chromium.org/developers/design-documents/displaying-a-web-page-in-chrome
>
> It has 2 messages as an example, "set cursor" message and  "mouse
> click" message.
>
> Does that mean there is a different message for each input events. For
> example,
> * a message for pressing each keyboard key (a-z,0-9)?
> * a message for mouse movement? (to support javascript onmouseover)
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Fixing our keyboard handling act on OSX

[Avi Drissman]

On Wed, May 27, 2009 at 6:14 PM, Jeremy Moskovich wrote:

> We also don't handle activation/deactivation of edit menu items correctly
> (select all is always disabled).
>

That's http://crbug.com/8662.

Standard commands (Copy/Paste/Select-all):
>

Your proposal sounds reasonable, but only if we do it for all platforms.
Right now there's a lot of hard-coding done in the editor client that's
Windows-only, and there are a lot of places where Windows has the same
issues (e.g. activating/deactivating cut/copy/paste).


> Emacs keyboard commands and IMEs:
>
> A possible solution to this would be to store a queue of the last N
> NSEvents per renderer matched with an ID.  the event would then be
> serialized and sent to the renderer which could then send it's own IPC
> message back to the browser process to get Cocoa to handle the message, we
> could pick the NSEvent out of the queue by ID and send back the relevant
> edit command to the renderer.
>

We already do much of this. Take a look at
TabContentsViewMac::HandleKeyboardEvent, where ids referring to keyboard
events not handled by WebKit are returned to the browser process.
TabContentsViewMac then retrieves the original event and passes it up to
Cocoa for handling. That might be an opportune time to Do The Right Thing.

How do IMEs belong here?

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Renderers "Not Responding"

[Avi Drissman]

Confirmed by experiment: the sandbox isn't the issue.

Avi

On Fri, May 22, 2009 at 2:42 PM, John Grabowski  wrote:

> No, for 2 reasons.One, we [NSApp mainApplication] before turning on the
> sandbox. (Yes, that's bad.)
> Two, the essence of the problem is that no thread in the renderer ever does
> a MessageLoopForUI or [NSRunLoop run].
>
> In the longer term we want to remove all Cocoa from the renderer.  But in
> the short term, for this 'spin' problem, I think Avi has it right --
> "MessageLoopForIO in renderer_main in a non-main thread and make a
> MessageLoopForUI on the main thread."
>
> jrg
>
> On Fri, May 22, 2009 at 11:36 AM, Mike Pinkerton 
> wrote:
>
>>
>> Does the problem go away if we disable the sandbox?
>>
>> On Fri, May 22, 2009 at 2:02 PM, Jeremy Moskovich 
>> wrote:
>> > I just pinged Avi about us, my guess is that the Sandbox is blocking
>> > connections ot the Window Server.
>> > Adding (debug deny) to the sandbox spec file will print messages to
>> console
>> > when things like this happen, I'll add a note about that to the Wiki
>> > (http://dev.chromium.org/developers/debugging-on-os-x).
>> > Best regards,
>> > Jeremy
>> >
>> > On Fri, May 22, 2009 at 10:54 AM, Avi Drissman  wrote:
>> >>
>> >> A visitor to IRC pointed me today to http://crbug.com/11319 , where
>> >> renderers are marked as "not responding". He pointed out that this is
>> not
>> >> just a cosmetic issue, since things like spindump run which kills
>> >> performance on non-quad core machines (that we all have).
>> >>
>> >> I thought about just pumping events on a non-main thread, but it turns
>> out
>> >> that NSApp nextEventMatchingMask returns nil when you don't run it on
>> the
>> >> main thread and doesn't pull any windowserver events.
>> >>
>> >> I thought about going for LSBackgroundOnly, but 1) we don't have a
>> >> separate bundle for the renderer and 2) I don't know if that fixes our
>> >> problem.
>> >>
>> >> The only thing I can think of now is to create the MessageLoopForIO in
>> >> renderer_main in a non-main thread and make a MessageLoopForUI on the
>> main
>> >> thread.
>> >>
>> >> Any thoughts on how to better do this?
>> >>
>> >> Avi
>> >
>> >
>>
>>
>>
>> --
>> Mike Pinkerton
>> Mac Weenie
>> pinker...@google.com
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Renderers "Not Responding"

[Avi Drissman]

A visitor to IRC pointed me today to http://crbug.com/11319 , where
renderers are marked as "not responding". He pointed out that this is not
just a cosmetic issue, since things like spindump run which kills
performance on non-quad core machines (that we all have).

I thought about just pumping events on a non-main thread, but it turns out
that NSApp nextEventMatchingMask returns nil when you don't run it on the
main thread and doesn't pull any windowserver events.

I thought about going for LSBackgroundOnly, but 1) we don't have a separate
bundle for the renderer and 2) I don't know if that fixes our problem.

The only thing I can think of now is to create the MessageLoopForIO in
renderer_main in a non-main thread and make a MessageLoopForUI on the main
thread.

Any thoughts on how to better do this?

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Tab-modal dialogs on the Mac

[Avi Drissman]

On Wed, May 20, 2009 at 6:44 PM, Mark Mentovai  wrote:

> Avi and I found that the Exposé funkiness, present on his Leopard
> machine and my Leopard laptop last week, is all of the sudden gone on
> my Leopard laptop this week.  The difference?  10.5.7, most likely.
>

Experimenting on various 10.5.6 and 10.5.7 machines leads me to this
conclusion as well.

I take from the silence that people are pretty happy with this, then. If so,
I'll wind things down with DTS and figure out how to test-ify it for
acceptance into GTM.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Help needed for Chromium on the Mac refresh problem...

[Avi Drissman]

Not really. Double-check all your coordinates, though. (For a while, I was
logging every coordinate as it passed through every function.)

Avi

On Thu, May 14, 2009 at 12:23 PM, Marc-Andre Decoste  wrote:

> Here's what we're now doing on the renderer side:
>
>- In the render widget, we now keep all invalidation as an independent
>sub-rect in a vector as opposed to union them as we used to.
>- Once, we are ready to paint:
>   - We create a bitmap that is the size of the whole view and wrap it
>   in a canvas.
>   - For each invalidation sub-rec
>  - We set a clip rect (on the canvas) to the invalidation
>  sub-rect.
>  - And then we call WebWidget::Paint() with the canvas and the
>  sub-rect.
>
>Anything smells fishy in there?
>
> BYE
> MAD
>
>
> On Thu, May 14, 2009 at 3:14 PM, Avi Drissman  wrote:
>
>> We haven't drawn one big rectangle for a long while. It took me a while to
>> fiddle with the transforms to get it all right, but we correctly blit small
>> rectangles for small updates (e.g. cursor blinks).
>>
>> OTOH, Mike has a point, that getting the coordinate transforms correct is
>> important, tricky, and a pain in the rear. That still might be the issue.
>> But if you're just calling into the RWHV repeatedly, it should handle it
>> just fine.
>>
>> Avi
>>
>> On Thu, May 14, 2009 at 12:02 PM, Mike Pinkerton 
>> wrote:
>>
>>>
>>> Just off the top of my head, it could be a coordinate problem. Cocoa
>>> uses a bottom-left coordinate system (the bottom left of the view is
>>> 0,0 as opposed to the top left). Since before we were just drawing a
>>> single big rectangle, it might not have mattered if we forgot to do
>>> the coordinate flipping. Again, just a wild guess based on things I've
>>> seen in the past and differences in the drawing paths.
>>>
>>> On Thu, May 14, 2009 at 2:33 PM, Marc-Andre Decoste 
>>> wrote:
>>> > Salut Adam,
>>> >The problem is that I'm missing some refreshes... I see them more
>>> clearly
>>> > when interacting with Google maps, or a little HTML page I created that
>>> has
>>> > buttons that change the content of scattered table cells to force
>>> multiple
>>> > individual rect invalidations in one shot... And those don't display if
>>> I
>>> > try to paint individual rects in the bitmap...
>>> >But it all works fine if I paint the whole bitmap, and then only
>>> draw the
>>> > sub-rects from the bitmap... This is why I think the new Mac specific
>>> code
>>> > is correct... Otherwise, I don't see how I would see the correct
>>> refreshes
>>> > in that latter case... Unless I missed something...
>>> >
>>> > Thanks!
>>> > BYE
>>> > MAD
>>> > On Thu, May 14, 2009 at 2:27 PM, Adam Langley 
>>> wrote:
>>> >>
>>> >> On Thu, May 14, 2009 at 11:21 AM, Marc-Andre Decoste 
>>> >> wrote:
>>> >> >Since there is a change in the Windows specific code of the
>>> renderer
>>> >> > host
>>> >> > backing store (to draw the sub-rects of the passed bitmap), I
>>> thought my
>>> >> > goof could have been in my adaptation of the Mac version of that
>>> code
>>> >> > (http://codereview.chromium.org/108040/diff/2038/3040). But it
>>> seems to
>>> >> > be
>>> >> > working fine if I disable the other part of that change (which is to
>>> >> > paint
>>> >> > only sub-rectangles in the bitmap). So if I paint a complete bitmap,
>>> and
>>> >> > pass it to the host with a list of sub-rectagles to draw... It
>>> works...
>>> >> > So I
>>> >> > guess the goof is in the code that paint sub-rectangles in the
>>> bitmap...
>>> >> >But this code works fine on Windows and is not done in a Windows
>>> >> > specific
>>> >> > way... So I'm kind of lost and don't know where to look... Anybody
>>> has a
>>> >> > clue here?
>>> >>
>>> >> What's the problem that you see?
>>> >>
>>> >> Surely it could still be in the Mac specific code if you're painting
>>> >> from the wrong regions in the bitmap?
>>> >>
>>> >>
>>> >> AGL
>>> >
>>> >
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> Mike Pinkerton
>>> Mac Weenie
>>> pinker...@google.com
>>>
>>>
>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Help needed for Chromium on the Mac refresh problem...

[Avi Drissman]

We haven't drawn one big rectangle for a long while. It took me a while to
fiddle with the transforms to get it all right, but we correctly blit small
rectangles for small updates (e.g. cursor blinks).

OTOH, Mike has a point, that getting the coordinate transforms correct is
important, tricky, and a pain in the rear. That still might be the issue.
But if you're just calling into the RWHV repeatedly, it should handle it
just fine.

Avi

On Thu, May 14, 2009 at 12:02 PM, Mike Pinkerton wrote:

>
> Just off the top of my head, it could be a coordinate problem. Cocoa
> uses a bottom-left coordinate system (the bottom left of the view is
> 0,0 as opposed to the top left). Since before we were just drawing a
> single big rectangle, it might not have mattered if we forgot to do
> the coordinate flipping. Again, just a wild guess based on things I've
> seen in the past and differences in the drawing paths.
>
> On Thu, May 14, 2009 at 2:33 PM, Marc-Andre Decoste 
> wrote:
> > Salut Adam,
> >The problem is that I'm missing some refreshes... I see them more
> clearly
> > when interacting with Google maps, or a little HTML page I created that
> has
> > buttons that change the content of scattered table cells to force
> multiple
> > individual rect invalidations in one shot... And those don't display if I
> > try to paint individual rects in the bitmap...
> >But it all works fine if I paint the whole bitmap, and then only draw
> the
> > sub-rects from the bitmap... This is why I think the new Mac specific
> code
> > is correct... Otherwise, I don't see how I would see the correct
> refreshes
> > in that latter case... Unless I missed something...
> >
> > Thanks!
> > BYE
> > MAD
> > On Thu, May 14, 2009 at 2:27 PM, Adam Langley  wrote:
> >>
> >> On Thu, May 14, 2009 at 11:21 AM, Marc-Andre Decoste 
> >> wrote:
> >> >Since there is a change in the Windows specific code of the
> renderer
> >> > host
> >> > backing store (to draw the sub-rects of the passed bitmap), I thought
> my
> >> > goof could have been in my adaptation of the Mac version of that code
> >> > (http://codereview.chromium.org/108040/diff/2038/3040). But it seems
> to
> >> > be
> >> > working fine if I disable the other part of that change (which is to
> >> > paint
> >> > only sub-rectangles in the bitmap). So if I paint a complete bitmap,
> and
> >> > pass it to the host with a list of sub-rectagles to draw... It
> works...
> >> > So I
> >> > guess the goof is in the code that paint sub-rectangles in the
> bitmap...
> >> >But this code works fine on Windows and is not done in a Windows
> >> > specific
> >> > way... So I'm kind of lost and don't know where to look... Anybody has
> a
> >> > clue here?
> >>
> >> What's the problem that you see?
> >>
> >> Surely it could still be in the Mac specific code if you're painting
> >> from the wrong regions in the bitmap?
> >>
> >>
> >> AGL
> >
> >
> > >
> >
>
>
>
> --
> Mike Pinkerton
> Mac Weenie
> pinker...@google.com
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Why is the Mac Omnibox stealing focus?

[Avi Drissman]

OK, so this was
r15790<http://src.chromium.org/viewvc/chrome?view=rev&revision=15790>.
The code already exists to set the focus to the location bar if it already
had it, though.

Avi

On Wed, May 13, 2009 at 2:24 PM, Avi Drissman  wrote:

> I'm implementing save/restore focus when switching tabs, and a recent
> checkin on the Mac omnibox is causing it to steal the focus. To see this:
>
> (gdb) b -[NSWindow makeFirstResponder:]
>
> Then switch tabs:
>
> #5  0x961f7f7b in -[NSTextField becomeFirstResponder] ()
> #6  0x000c209f in AutocompleteEditViewMac::UpdateAndStyleText
> (this=0x595a220, display_te...@0x595a260, user_text_length=0) at
> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:281
> #7  0x000c24d7 in AutocompleteEditViewMac::SetWindowTextAndCaretPos
> (this=0x595a220, te...@0x595a260, caret_pos=0) at
> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:203
> #8  0x000bcd36 in AutocompleteEditModel::Revert (this=0x595a250) at
> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit.cc:174
> #9  0x000c23bd in AutocompleteEditViewMac::RevertAll (this=0x595a220) at
> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:215
> #10 0x000c25b4 in AutocompleteEditViewMac::Update (this=0x595a220,
> tab_for_state_restoring=0x619da00) at
> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:125
> #11 0x001862bf in LocationBarViewMac::Update (this=0x5959720,
> contents=0x619da00, should_restore_state=true) at
> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> location_bar_view_mac.mm:62
> #12 0x00197ac8 in -[ToolbarController
> updateToolbarWithContents:shouldRestoreState:] (self=0x59554a0,
> _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at
> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> toolbar_controller.mm:102
> #13 0x00181465 in -[BrowserWindowController
> updateToolbarWithContents:shouldRestoreState:] (self=0x5944880,
> _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at
> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> browser_window_controller.mm:305
> #14 0x0017f1ff in BrowserWindowCocoa::UpdateToolbar (this=0x5949b10,
> contents=0x619da00, should_restore_state=true) at
> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> browser_window_cocoa.mm:145
> #15 0x00127b49 in Browser::UpdateToolbar (this=0x59432c0,
> should_restore_state=true) at
> /Users/avi/Source/chrome/src/chrome/browser/browser.cc:2257
>
> UpdateToolbar ends up in AutocompleteEditViewMac::UpdateAndStyleText()
> which, on lines 280-3 insists on becoming the keyboard focus. Why?
>
> Avi
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Why is the Mac Omnibox stealing focus?

[Avi Drissman]

OK. Will update my bug with that blocker info.

Avi

On Wed, May 13, 2009 at 2:34 PM, Scott Hess  wrote:

> The "why" is probably because I misunderstood something.  With an
> NSTextField there, we can't set the selection without having focus,
> which may have confused me into grabbing focus in cases where it isn't
> needed (or requested).  I've been spending some time figuring out
> where all that code can get called from.  Now that some of the other
> code is more fleshed out, the original reason for it to be there might
> be completely gone.
>
> http://crbug.com/11920
>
> -scott
>
>
> On Wed, May 13, 2009 at 2:27 PM, Avi Drissman  wrote:
> > OK, so this was r15790. The code already exists to set the focus to the
> > location bar if it already had it, though.
> >
> > Avi
> >
> > On Wed, May 13, 2009 at 2:24 PM, Avi Drissman  wrote:
> >>
> >> I'm implementing save/restore focus when switching tabs, and a recent
> >> checkin on the Mac omnibox is causing it to steal the focus. To see
> this:
> >>
> >> (gdb) b -[NSWindow makeFirstResponder:]
> >>
> >> Then switch tabs:
> >>
> >> #5  0x961f7f7b in -[NSTextField becomeFirstResponder] ()
> >> #6  0x000c209f in AutocompleteEditViewMac::UpdateAndStyleText
> >> (this=0x595a220, display_te...@0x595a260, user_text_length=0) at
> >> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:281
> >> #7  0x000c24d7 in AutocompleteEditViewMac::SetWindowTextAndCaretPos
> >> (this=0x595a220, te...@0x595a260, caret_pos=0) at
> >> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:203
> >> #8  0x000bcd36 in AutocompleteEditModel::Revert (this=0x595a250) at
> >>
> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit.cc:174
> >> #9  0x000c23bd in AutocompleteEditViewMac::RevertAll (this=0x595a220) at
> >> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:215
> >> #10 0x000c25b4 in AutocompleteEditViewMac::Update (this=0x595a220,
> >> tab_for_state_restoring=0x619da00) at
> >> /Users/avi/Source/chrome/src/chrome/browser/autocomplete/
> autocomplete_edit_view_mac.mm:125
> >> #11 0x001862bf in LocationBarViewMac::Update (this=0x5959720,
> >> contents=0x619da00, should_restore_state=true) at
> >> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> location_bar_view_mac.mm:62
> >> #12 0x00197ac8 in -[ToolbarController
> >> updateToolbarWithContents:shouldRestoreState:] (self=0x59554a0,
> >> _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at
> >> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> toolbar_controller.mm:102
> >> #13 0x00181465 in -[BrowserWindowController
> >> updateToolbarWithContents:shouldRestoreState:] (self=0x5944880,
> >> _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at
> >> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> browser_window_controller.mm:305
> >> #14 0x0017f1ff in BrowserWindowCocoa::UpdateToolbar (this=0x5949b10,
> >> contents=0x619da00, should_restore_state=true) at
> >> /Users/avi/Source/chrome/src/chrome/browser/cocoa/
> browser_window_cocoa.mm:145
> >> #15 0x00127b49 in Browser::UpdateToolbar (this=0x59432c0,
> >> should_restore_state=true) at
> >> /Users/avi/Source/chrome/src/chrome/browser/browser.cc:2257
> >>
> >> UpdateToolbar ends up in AutocompleteEditViewMac::UpdateAndStyleText()
> >> which, on lines 280-3 insists on becoming the keyboard focus. Why?
> >>
> >> Avi
> >
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Why is the Mac Omnibox stealing focus?

[Avi Drissman]

I'm implementing save/restore focus when switching tabs, and a recent
checkin on the Mac omnibox is causing it to steal the focus. To see this:

(gdb) b -[NSWindow makeFirstResponder:]

Then switch tabs:

#5  0x961f7f7b in -[NSTextField becomeFirstResponder] ()
#6  0x000c209f in AutocompleteEditViewMac::UpdateAndStyleText
(this=0x595a220, display_te...@0x595a260, user_text_length=0) at
/Users/avi/Source/chrome/src/chrome/browser/autocomplete/
autocomplete_edit_view_mac.mm:281
#7  0x000c24d7 in AutocompleteEditViewMac::SetWindowTextAndCaretPos
(this=0x595a220, te...@0x595a260, caret_pos=0) at
/Users/avi/Source/chrome/src/chrome/browser/autocomplete/
autocomplete_edit_view_mac.mm:203
#8  0x000bcd36 in AutocompleteEditModel::Revert (this=0x595a250) at
/Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit.cc:174
#9  0x000c23bd in AutocompleteEditViewMac::RevertAll (this=0x595a220) at
/Users/avi/Source/chrome/src/chrome/browser/autocomplete/
autocomplete_edit_view_mac.mm:215
#10 0x000c25b4 in AutocompleteEditViewMac::Update (this=0x595a220,
tab_for_state_restoring=0x619da00) at
/Users/avi/Source/chrome/src/chrome/browser/autocomplete/
autocomplete_edit_view_mac.mm:125
#11 0x001862bf in LocationBarViewMac::Update (this=0x5959720,
contents=0x619da00, should_restore_state=true) at
/Users/avi/Source/chrome/src/chrome/browser/cocoa/
location_bar_view_mac.mm:62
#12 0x00197ac8 in -[ToolbarController
updateToolbarWithContents:shouldRestoreState:] (self=0x59554a0,
_cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at
/Users/avi/Source/chrome/src/chrome/browser/cocoa/toolbar_controller.mm:102
#13 0x00181465 in -[BrowserWindowController
updateToolbarWithContents:shouldRestoreState:] (self=0x5944880,
_cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at
/Users/avi/Source/chrome/src/chrome/browser/cocoa/
browser_window_controller.mm:305
#14 0x0017f1ff in BrowserWindowCocoa::UpdateToolbar (this=0x5949b10,
contents=0x619da00, should_restore_state=true) at
/Users/avi/Source/chrome/src/chrome/browser/cocoa/
browser_window_cocoa.mm:145
#15 0x00127b49 in Browser::UpdateToolbar (this=0x59432c0,
should_restore_state=true) at
/Users/avi/Source/chrome/src/chrome/browser/browser.cc:2257

UpdateToolbar ends up in AutocompleteEditViewMac::UpdateAndStyleText()
which, on lines 280-3 insists on becoming the keyboard focus. Why?

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Tab-modal dialogs on the Mac

[Avi Drissman]

Thanks.

So I fiddled with the "hiding sheets" part, and now leave the sheet in place
but make it fully transparent. That helps a lot with some expose issues (and
all the ones still left are fixed in SL). That leaves the fact that the
shouldterminate delegate call is broken and that event handling and fuzzing
issues are entirely broken on SL.

Unless someone has any thoughts on that, I'm going to drop DTS a call later
today. Code's in my experimental directory for anyone wanting to play with
it.

Avi

On Fri, May 8, 2009 at 1:35 PM, Mark Mentovai  wrote:

> Amanda Walker wrote:
> > Yeah.  And I have to say, the tab-modal file sheet is very, very cool.
> >  It would be a shame to lose that capability.
>
> I agree, I think it'd be worth seeing how polished we can get things
> with Avi's POC.  It's a cool behavior that has the exact "feel" that
> sheet users would expect.
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Tab-modal dialogs on the Mac

[Avi Drissman]

The problem with that approach is that you can't cleanly close a sheet in
the general case. If it's our sheet then perhaps that'd work, but for
something like the save file sheet, there's no good way to convince it to
close that isn't more hacky than what I'm doing...

Avi

On Fri, May 8, 2009 at 12:44 PM, Scott Hess  wrote:

> I hate to suggest this, since it's sort of icky (*), but would it make
> sense to instead use regular old sheets, and save/restore state across
> tab switches?  I mean so that if the tab is not visible, there is no
> OS-level sheet, there's a state container somewhere in the tab which
> will be restored with the tab.  That should short-circuit a lot of
> funky interactions that are broken in places we cannot see them, at a
> cost of making some "for free" stuff not work (we'll have to manually
> manage those interactions).
>
> (*) I don't like icky, but icky where you own the code is preferable
> to icky where you're having to reverse-engineer someone else's code.
>
> -scott
>
>
> On Fri, May 8, 2009 at 11:20 AM, Avi Drissman  wrote:
> > On Thu, May 7, 2009 at 9:49 AM, Mark Mentovai  wrote:
> >>
> >> Hit "login", then play with Exposé.  The "show me my desktop" function
> >> leaves the sheet hanging; the "show me my app's windows" and "show me
> >> all windows" functions send the sheet offscreen.
> >
> > These are all fixed by the system in SL.
> > Unfortunately, everything else is broken in SL. Putting the sheet back
> > leaves it ignoring all mouse input, and when it's hidden the blurring
> effect
> > on the host window remains.
> > Urgh.
> > I've fiddled around with several approaches and gotten nowhere. I might
> end
> > up having to use that DTS incident after all...
> > Avi
> > > >
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Tab-modal dialogs on the Mac

[Avi Drissman]

On Thu, May 7, 2009 at 9:49 AM, Mark Mentovai  wrote:

> Hit "login", then play with Exposé.  The "show me my desktop" function
> leaves the sheet hanging; the "show me my app's windows" and "show me
> all windows" functions send the sheet offscreen.
>

These are all fixed by the system in SL.

Unfortunately, everything else is broken in SL. Putting the sheet back
leaves it ignoring all mouse input, and when it's hidden the blurring effect
on the host window remains.

Urgh.

I've fiddled around with several approaches and gotten nowhere. I might end
up having to use that DTS incident after all...

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Tab-modal dialogs on the Mac

[Avi Drissman]

On Thu, May 7, 2009 at 9:49 AM, Mark Mentovai  wrote:

> multisheet
> disables x and - (there is no +, but I assume it'd be disabled too).
> It shouldn't disable - and +.
>

I don't think I have control over that. I don't think that Cocoa's support
for child windows putting up sheets is quite complete.

>
> ab-modality in
> the face of a closing window seems like it needs some careful thought
> and planning.
>

I added methods to the controller to get the views with tabs and am
recommending that any users of the class disallow closing of the window
while tabs are up.


> (Maybe the right thing to
> do, in this case and the window-close case, is to switch to the tab
> with the sheet?  What if there are multiple sheets open?)


If there are multiple sheets open, then it's the job of the app logic to
decide what to do. In the simple case that I include, if the current tab has
a sheet I leave it up, otherwise I switch to the first tab that has a sheet.

The quit case is a little bit nastier. The problem is that when you have a
hidden sheet up, -applicationShouldTerminate actually *doesn't get
called!*I'm still trying to figure this one out.

I think that the tab
> control should not be greyed out at all, since it is directly usable.
>

That's a few hours of futzing with focus issues. For our use cases, is it
worth it? After all, we're likely to be using it in cases where we control
the drawing of the controls. Punting for now.


> Hit "login", then play with Exposé.  The "show me my desktop" function
> leaves the sheet hanging; the "show me my app's windows" and "show me
> all windows" functions send the sheet offscreen.
>

You forgot to note that if the sheet is hidden and you do a "show app
windows" or "show all windows" the fact that I hide the window off-screen
wrecks everyone's position.

I'm going to have to wrestle with Exposé for that. There's no API to make a
window hide from Exposé in Leopard or below and the SPIs I've tried aren't
working. I'm going to play with Sno... um, a beta OS to see what I find.

Visually, Cocoa sheets have a bit of a shadow at the top, making it
> look like they've slid out from the parent window.  The multisheet
> looks like it slides out of thin air and then just hangs there.
>

I remember reading that it's a window that does that. I can't convince Cocoa
to do that. Visual; punting.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Tab-modal dialogs on the Mac

[Avi Drissman]

1. Naming's arbitrary. The name "hanger window" comes from an earlier design
idea where the clear window was sized only 10 px high, and was the "hanger"
upon which the sheet hung. Once I got the idea that I could also use it to
block input to the underlying view, I guess it outgrew the name. (shrug)

2. It was made separable just so I could easily move it from the POC to
Chromium, but I'm open to GTMing it. Dave, are there any features you'd like
to see?

Avi

On Thu, May 7, 2009 at 7:49 AM, Mike Pinkerton wrote:

> I dig it! NICE!
>
> It's similar to the overlay window trick we use for tab dragging
> between windows. Maybe for consistency you should call the "hanger"
> window the "overlay" window?
>
> Is there any way we can keep this generic and put it into GTM?
>
> On Thu, May 7, 2009 at 8:46 AM, Amanda Walker  wrote:
> > That's cleaner than I expected, and the behavior looks right.  Nice
> > job!  I vote for continuing with this approach.
> >
> > --Amanda
> >
> > On Thu, May 7, 2009 at 12:17 AM, Avi Drissman  wrote:
> >> OK, so attached is my proof of concept. The code is pretty clear, though
> if
> >> you have questions, please let me know.
> >>
> >> +maf: Your offhand comment about tabs being subwindows led me to this
> >> implementation; thanks!
> >> +dmac: What do you think? I'll send the DTS incident back to you
> tomorrow.
> >>
> >> Avi
> >>
> >> On Tue, May 5, 2009 at 2:40 PM, Avi Drissman  wrote:
> >>>
> >>> Having signed up for the login dialog, I'm seeing that it's a pretty
> >>> interesting subject. If you try out a page with HTTP auth, you'll see
> that
> >>> you get what looks like a dialog for the username and password. But if
> you
> >>> click around, you find that you can switch tabs, and that the dialog is
> >>> tab-modal. In fact, the UI test has a test
> (LoginPromptTest.TestTwoAuths) to
> >>> make sure that you can have two auths going on at once.
> >>>
> >>> I was thinking about doing this as a sheet, but that's window-modal and
> of
> >>> less functionality. I can play games with dialogs (making them child
> windows
> >>> and/or hiding/showing along with the tab) but that gets to be less
> Mac/like.
> >>>
> >>> As I type this I wonder if we can get a sheet to come down under the
> tab
> >>> bar and hide/show it with the tab. Would that be good UI-wise?
> >>>
> >>> And of course, I'd probably retrofit the file picker to do that too.
> >>>
> >>> Thoughts?
> >>>
> >>> Avi
> >>
> >>
> >
>
>
>
> --
> Mike Pinkerton
> Mac Weenie
> pinker...@google.com
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Tab-modal dialogs on the Mac

[Avi Drissman]

I need to play with this. It's pretty obvious how this would have been done
in Carbon (where you can attach/detach sheets with abandon) but it's less
obvious how to do this in Cocoa, where -[NSWindow attachedSheet] implies
just one sheet per window, and it's not obvious how to attach a sheet to a
window without also running an event loop.

The alternative is to create a window in sheet style but attach it
ourselves. Then the question is faking the reveal effect. Once again, it's
obvious how to do it in Carbon (WindowTransitionEffect) but less so in
Cocoa.

If anyone has immediate answers let me know. Otherwise I'll see what I can
wrestle up.

Avi

On Tue, May 5, 2009 at 2:43 PM, Amanda Walker  wrote:

> I'd be worried about flashing/jankiness using a real sheet, but a
> child window pinned to the top edge of the tab with the right
> transitions might work nicely.  There's also some stuff Jeremy was
> doing in Gears that involved doing interesting things with login
> prompts that may (or may not) be relevant.  It would certainly be nice
> to keep things tab-modal, even though Cocoa doesn't really grok that
> idea.
>
> --Amanda
>
>
> On Tue, May 5, 2009 at 5:40 PM, Avi Drissman  wrote:
> > Having signed up for the login dialog, I'm seeing that it's a pretty
> > interesting subject. If you try out a page with HTTP auth, you'll see
> that
> > you get what looks like a dialog for the username and password. But if
> you
> > click around, you find that you can switch tabs, and that the dialog is
> > tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths)
> to
> > make sure that you can have two auths going on at once.
> >
> > I was thinking about doing this as a sheet, but that's window-modal and
> of
> > less functionality. I can play games with dialogs (making them child
> windows
> > and/or hiding/showing along with the tab) but that gets to be less
> Mac/like.
> >
> > As I type this I wonder if we can get a sheet to come down under the tab
> bar
> > and hide/show it with the tab. Would that be good UI-wise?
> >
> > And of course, I'd probably retrofit the file picker to do that too.
> >
> > Thoughts?
> >
> > Avi
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Tab-modal dialogs on the Mac

[Avi Drissman]

I don't think that's important.

Avi

On Tue, May 5, 2009 at 2:46 PM, Evan Martin  wrote:

> One question that's been on my mind is how important it is for the
> dialog to be draggable.
> We can't simultaneously do (normal window title bar) and (constrained
> to a tab) on Linux.
> A Mac-style "sheet" would be consistent with other tab-related UI like
> the find bar.
>
> On Tue, May 5, 2009 at 2:40 PM, Avi Drissman  wrote:
> > Having signed up for the login dialog, I'm seeing that it's a pretty
> > interesting subject. If you try out a page with HTTP auth, you'll see
> that
> > you get what looks like a dialog for the username and password. But if
> you
> > click around, you find that you can switch tabs, and that the dialog is
> > tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths)
> to
> > make sure that you can have two auths going on at once.
> >
> > I was thinking about doing this as a sheet, but that's window-modal and
> of
> > less functionality. I can play games with dialogs (making them child
> windows
> > and/or hiding/showing along with the tab) but that gets to be less
> Mac/like.
> >
> > As I type this I wonder if we can get a sheet to come down under the tab
> bar
> > and hide/show it with the tab. Would that be good UI-wise?
> >
> > And of course, I'd probably retrofit the file picker to do that too.
> >
> > Thoughts?
> >
> > Avi
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Tab-modal dialogs on the Mac

[Avi Drissman]

Having signed up for the login dialog, I'm seeing that it's a pretty
interesting subject. If you try out a page with HTTP auth, you'll see that
you get what looks like a dialog for the username and password. But if you
click around, you find that you can switch tabs, and that the dialog is
tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to
make sure that you can have two auths going on at once.

I was thinking about doing this as a sheet, but that's window-modal and of
less functionality. I can play games with dialogs (making them child windows
and/or hiding/showing along with the tab) but that gets to be less Mac/like.

As I type this I wonder if we can get a sheet to come down under the tab bar
and hide/show it with the tab. Would that be good UI-wise?

And of course, I'd probably retrofit the file picker to do that too.

Thoughts?

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Unforking: Canary Bot Lives!

[Avi Drissman]

Whoo!!!

Partay!

Avi

On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov wrote:

>
> Hello all,
>
> This is kind of a momentous occasion. For the first time -- ever, our
> WebKit Canary bot (the one that pulls directly from WebKit upstream)
> has built successfully and was able to run tests:
>
>
> http://build.chromium.org/buildbot/waterfall.fyi/builders/Webkit%20(webkit.org)/builds/2937
>
> What does this mean? This means that our unforking efforts have
> finally paid off -- we can now pull directly from WebKit upstream!
>
> Congratulations to all of you who worked and helped during the last 7
> months! This was a long run, and despite various setbacks, we have
> reached this milestone.
>
> This also means that the daily merge as we know it is soon to be
> replaced with a less daunting activity -- WebKit gardening. I am
> working on the document to define what this will entail. Stay tuned.
>
> :DG<
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Suggestion for crossplatform ProcessSingleton and ChromeBrowserProcessId()

[Avi Drissman]

On Mon, Apr 27, 2009 at 11:21 AM, Evan Martin  wrote:

> That leaves process_util for Linux and Mac, which uses fuser (or
> something similar) and that is a hack.  However, it's only used for ui
> tests, I believe -- it's not needed in normal usage.


The Mac uses ps -xw, but the same reasoning applies. It's rather hacky, but
I'm in the same position as you, that since it's only used during testing,
that's OK. (And in fact, the Mac version as it exists today would only work
during testing so we're sure that no one will start using it in the actual
app.)


> I am not opposed
> to (lazily, on a background thread) writing a pid file on Linux,
> though I'd prefer some other solution if one could be found.


I'm not fond of the idea, as it just litters things up. And since it's only
needed for testing the app, but it would be written all the time (testing or
not) it's just wasteful.


> Maybe
> it's to just remove the need for ChromeBrowserProcessId() somehow.


It would be nice, but that's used to test the spawning of processes, so it
might not be easily expurgated.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] FilePath::Extension() and dots

[Avi Drissman]

Erik—

I don't understand why in http://codereview.chromium.org/17243 you defined
Extension() to have a leading dot. It's easier to add a dot than take one
off, and I don't understand why you insist on the equivalence you describe.
How is ensuring that you could append the string values of the file and its
extension together useful?

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Mac/Linux heads-up: RenderWidgetHostView changes needed

[Avi Drissman]

On Mon, Apr 13, 2009 at 2:47 PM, Peter Kasting  wrote:

> it doesn't fire on Mac and at some point Avi will fix the Mac
> implementation.
>

Side note: I now understand the issue this fixes and the fix to make the Mac
impl compliant and to handle this one is item #2 on my todo list.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Mac/Linux heads-up: RenderWidgetHostView changes needed

[Avi Drissman]

On Mon, Apr 13, 2009 at 12:13 PM, Darin Fisher  wrote:

> You need to change the Mac implementation to flush to the screen when
> DidPaintRect is not called withing drawRect / GetBackingStore.
>

I'll put it on my list of things to do. (First is fixing a bug that is
causing drawing to not work at all.)

Research time, though, how to do a direct draw in Cocoa.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Mac/Linux heads-up: RenderWidgetHostView changes needed

[Avi Drissman]

I'm still a little lost in this discussion. I'm repeatedly reading the code
and the patch, and I'll get back to you when I fully understand it. But what
I wanted to say is that there is a significant difference in the paint
pipeline as it currently exists on the Mac compared to Win/Lin.

On Win, DidPaintRect() calls Redraw() which calls
RedrawWindow(...RDW_UPDATENOW...) which (AFAIK) does a synchronous draw via
Win32 callback to OnPaint().

On Lin, DidPaintRect() calls Paint() which blits via
BackingStore::ShowRect(). Again, synchronously.

On Mac, DidPaintRect() calls Redraw() which calls -[NSView
setNeedsDisplayInRect:], setting the damaged rect in the view. The call
returns, and sometime later, during the next pump of the message loop, Cocoa
wakes up, decides to repaint all damaged windows, calls our -drawRect:,
which then calls RenderWidgetHost::GetBackingStore().

That gap prevents recursion. If for some reason GetBackingStore ends up
causing a DidPaintRect() message, what will happen is:

- Original DidPaintRect(), adds damage
 ... message loop ...
- -drawRect:
-- GetBackingStore()
--- New DidPaintRect(), adds more damage
-- blitting
 ... Cocoa clears the damage region, all of it

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Splitting an existing resource

[Avi Drissman]

OK.

If I don't change the contents, do I then mark the old string as
"DEPRECATED" or something in the comments?

a

On Tue, Apr 7, 2009 at 1:30 PM, Tony Chang  wrote:

> Right, but it's safe to just change it in generated_resources.grd and in
> code because all the other locales will just fall back to the English
> translation in generated_resources.grd.  The magic ids won't match anymore
> since you changed the English string so everything will just default to the
> English text.
>
> On Tue, Apr 7, 2009 at 10:27 AM, Avi Drissman  wrote:
>
>>  I don't need it immediately. I can tear apart the string at the null
>> characters in code for now. It'd be nice to roll the strings, but that'd
>> need to be done in coordination with code.
>>
>> Avi
>>
>>
>> On Tue, Apr 7, 2009 at 1:23 PM, Tony Chang  wrote:
>>
>>> You can't split or change a string without going through the whole
>>> translation cycle.  The canonical source of translations is in the
>>> translation console, so even if you were to change all the .xtb files by
>>> hand, your change would get clobbered the next time we pulled translations
>>> from the translation console.
>>> Do you need the translation immediately or is it ok to change the .grd
>>> file and just wait for the translations?
>>>
>>> On Tue, Apr 7, 2009 at 8:48 AM, Avi Drissman  wrote:
>>>
>>>> http://dev.chromium.org/developers/design-documents/ui-localizationdescribes
>>>>  the process of adding a resource. It goes something like this:
>>>>
>>>> 1. Add the key to a .grd file
>>>> 2. ???
>>>> 3. Translations show up in .xtb files
>>>>
>>>> I need to split an existing key, though (one that is actually two
>>>> strings in the first place), and that's not helpful. I need to split
>>>> IDS_SAVE_PAGE_FILTER into two strings. I can change the .grd file, but all
>>>> the .xtbs have some magic "id" number that I can't find the origin of. Now,
>>>> once they're put into the generated_resources file they're matched up with
>>>> the tag that the grd file had, but that's too late.
>>>>
>>>> What's going on here? How do I split an existing string into two without
>>>> going through a whole translation cycle?
>>>>
>>>> Avi
>>>>
>>>> >>>>
>>>>
>>>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---