[chromium-dev] How to get a faster/smaller checkout?
Hi, It's noticed that a normal source code checkout by "gclient config ... && gclient sync" with default settings will cost a couple of hours via an ADSL, which is very time-consuming, and the result working copy will occupy about 2GB disk space, which is very space-consuming. There are many unused things for certain developers, for example, directories for "linux" or "mac" are not necessary to developers who only want to build Chrome on win32. Is there any official configuration file (the .gclient file) for win32 only checkout or linux/mac only checkout, which only checkouts minimum files for the specified platform? -- Hua --~--~-~--~~~---~--~~ 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: vs2008 and gyp
> (Oh and for the folks that added in boost, I'll be adding in an > MSVS_VERSION variable you'll be able to use at gyp time so you can have > different behaviors). > Good to know. BTW, boost got removed about 3 weeks ago after zhanyong broke the dependency from gmock to boost and tr1 (yay!). So no need to worry about it anymore! -Albert --~--~-~--~~~---~--~~ 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: vs2008 and gyp
Right click on my computer, select properties.Select advanced tab. Click on Environment Variables. Add a GYP_MSVS_VERSION variable set to 2008. Last I had heard the 2008 build is working, but it is less stable as we don't yet have a builder setup to validate it. And most folks are using 2005. -BradN On Wed, Jul 15, 2009 at 10:34 PM, Thiago Farina wrote: > > Is safe to try this option? Nothing will be broken? > Where I can set this variable? > > On Jun 4, 3:40 pm, Bradley Nelson wrote: > > Hi All, > > If you don't have Visual Studio 2008 installed you can stop reading. > > > > As many of you have no doubt noticed, gyp emits something approximating > > vs2008 sln/vcproj files for the portion of the build it has swallowed. > > Currently it decides to emit vs2008 format if vs2008 is installed. The > > auto-detect has been a problem for several people, since the extent to > which > > things build under vs2008 is unstable. > > > > I will be dropping a change in once the tree opens again to switch the > > default to vs2005. > > > > If you do want to play with the vs2008 option you can force it by setting > > GYP_MSVS_VERSION=2008 in your environment. > > > > Eventually we will add a vs2008 builder. But there seems like little > point > > at the moment, since not everything has been gypified (so the import step > > still happens). > > > > If you feel strongly about what the eventual behavior should be, let me > > know. > > > > (Oh and for the folks that added in boost, I'll be adding in an > MSVS_VERSION > > variable you'll be able to use at gyp time so you can have different > > behaviors). > > > > -BradN > > > --~--~-~--~~~---~--~~ 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: vs2008 and gyp
Is safe to try this option? Nothing will be broken? Where I can set this variable? On Jun 4, 3:40 pm, Bradley Nelson wrote: > Hi All, > If you don't have Visual Studio 2008 installed you can stop reading. > > As many of you have no doubt noticed, gyp emits something approximating > vs2008 sln/vcproj files for the portion of the build it has swallowed. > Currently it decides to emit vs2008 format if vs2008 is installed. The > auto-detect has been a problem for several people, since the extent to which > things build under vs2008 is unstable. > > I will be dropping a change in once the tree opens again to switch the > default to vs2005. > > If you do want to play with the vs2008 option you can force it by setting > GYP_MSVS_VERSION=2008 in your environment. > > Eventually we will add a vs2008 builder. But there seems like little point > at the moment, since not everything has been gypified (so the import step > still happens). > > If you feel strongly about what the eventual behavior should be, let me > know. > > (Oh and for the folks that added in boost, I'll be adding in an MSVS_VERSION > variable you'll be able to use at gyp time so you can have different > behaviors). > > -BradN --~--~-~--~~~---~--~~ 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: bug flag for flakiness-related bugs
Done. I named it FlakyTest since Flakiness seems like it could apply to other things besides just tests. -Darin On Wed, Jul 15, 2009 at 5:22 PM, Paweł Hajdan Jr. wrote: > > What do you think about creating a new flag for bugs about flaky > tests? Something like "Flakiness". > > It would be nice to have it as an official flag, so we don't end up > with few variants of the flag. > > > > --~--~-~--~~~---~--~~ 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: Problem in starting My Chromium on MacOSX
On Wed, Jul 15, 2009 at 4:18 PM, Jens Alfke wrote: > > On Jul 15, 2009, at 3:50 PM, Albert J. Wong (王重傑) wrote: > >> Since you built it, you should be able to fire it up in a debugger and see >> where it's dying. That's what I'd try first. > > More precisely: > * Open chrome.xcodeproj > * Make sure the "chrome" executable is active > * Choose Run > Activate Breakpoints > * Choose Run > Go > Thanks for all the help. I fix the problem by removing my ~/Library/Application Support/Chromium directory and start the chromium I built again. > —Jens --~--~-~--~~~---~--~~ 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: Creating a Custom View
Thanks for all of your help, it is much appreciated!
On 15 July, 12:39, PhistucK wrote:
> dev.chromium.org has a lot of info ("Getting around the source code" is an
> example).But in your case, you want it to start up without switches, you
> just want it to be your version from the beginning with no special attention
> (besides compiling).
>
> You cannot exactly 'upload the changes back to the Google servers', you can
> submit a patch that will incorporate your changes (little changes, do not
> bring up all of the changes because people review these patches), there is
> an explanation about this in dev.chromium.org too.
> One (or more) of the committers review your changes and if the changes were
> approved, they commit the change list (=patch).
>
> Before submitting a patch, you should first ask if this is possible, because
> maybe they are not ready for supporting multiple (external) branches yet.
>
> SVN should be fine about the changes, anyway, unless there are real
> conflicts.
> Just run "gclient sync" and everything will be fine (and if not, it will
> notify you with a confirmation and some options).
>
> About the switches, you can simply reverse the switch (with ! in the
> condition). But that will also give you the incognito features, which I am
> not sure you would really like to have.
>
> ☆PhistucK
>
>
>
> On Wed, Jul 15, 2009 at 13:33, Kruncher wrote:
>
> > I wasn't aware that SVN manages changes within the content of a file.
> > I am relatively new to open source code, and have only ever used SVN
> > to download the Chromium trunk. I also did not realize that it was
> > possible to upload changes back to the Google servers.
>
> > I will have to read up on how SVN works. Perhaps there is a reserved
> > comment/macro that can be used to protect a range of code.
>
> > Across several of the projects there appears to be an interface which
> > is responsible for constructing the required browser based upon
> > command switches. This interface is able to switch between starting up
> > with the standard and incognito windows, so I thought perhaps there
> > would be a way to override this.
>
> > Do you know of any documentation which explains the architecture of
> > Chromium, and the purpose of the various projects and files?
>
> > On 15 July, 10:41, PhistucK wrote:
> > > SVN usually manages to merge the changes you have made with the changes
> > from
> > > trunk, unless they have changed that same bit of code you have and then,
> > it
> > > says there is a conflict and lets you look at the differences. I modified
> > > things in the actual Chromium source, not in a new project.
>
> > > There was a thread about creating branches and they said it is better
> > > handled with GIT, though I have never used GIT and since almost all of my
> > > changes were only adding things\the code nearby the code I changes were
> > not
> > > changed, no conflicts occurred.
>
> > > If your changes can be incorporated into the code because most of what
> > they
> > > do is removing options, maybe you can even upload your changes to the
> > > Chromium source code (with #IF DEFINE YOUR_CUSTOM_CODE or something). But
> > > you have to ask them first, of course.
>
> > > ☆PhistucK
>
> > > On Wed, Jul 15, 2009 at 11:41, Kruncher wrote:
>
> > > > Thanks for your fast reply!
>
> > > > When you made your changes, did you start with a new project, or did
> > > > you edit the Chromium browser itself?
>
> > > > I was considering just modifying the browser. My concern was that if I
> > > > wanted to update the Chromium trunk, I would need to redo my various
> > > > changes to the system.
>
> > > > Thanks again,
>
> > > > On 15 July, 09:31, PhistucK wrote:
> > > > > It is actually pretty easy to do that, I guess.I changed chromium to
> > > > support
> > > > > another button in the toolbar with a keyboard shortcut and removed
> > the
> > > > > "About Chromium" menu really easily - and my knowledge in C++ is
> > nearly
> > > > > nonexistent (I only know the syntax since it is similar to
> > JavaScript).
>
> > > > > You should look at the code that uses the regular window and the code
> > > > that
> > > > > uses the incognito window (use the theme GRD files for hints to what
> > to
> > > > > search for, like the Incognito logo and its ID) and compare the two,
> > move
> > > > > the things that fit you from incognito back into the regular window.
> > > > > The debugger and everything, you can leave them in the code, simply
> > > > remove
> > > > > all of the reference to them, like menu items (pretty easy to find),
> > > > > keyboard shortcuts and context menu items.
>
> > > > > ☆PhistucK
>
> > > > > On Wed, Jul 15, 2009 at 10:50, Kruncher wrote:
>
> > > > > > Hi,
>
> > > > > > I would like to create a custom browser application based on the
> > > > > > Chromium source. I have downloaded and compiled the source (from
> > the
> > > > > > "Chrome.sln" solution.
>
> > > > > > What I want to do is:
> > > > > > - Create a new executab
[chromium-dev] Re: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 2:49 PM, Peter Kasting wrote: > On Wed, Jul 15, 2009 at 12:57 PM, Peter Kasting wrote: > >> This is my concern. A number of WebKit things at least used to only work >> with a Cygwin SVN checkout. >> > > Sadly, it looks as if this is still the case. Using Adam's instructions on > Windows results in a WebKit checkout where scripts like build-webkit do not > work. > I am now working on this upstream at https://bugs.webkit.org/show_bug.cgi?id=27323 . 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] bug flag for flakiness-related bugs
What do you think about creating a new flag for bugs about flaky tests? Something like "Flakiness". It would be nice to have it as an official flag, so we don't end up with few variants of the flag. --~--~-~--~~~---~--~~ 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: Problem in starting My Chromium on MacOSX
On Jul 15, 2009, at 3:50 PM, Albert J. Wong (王重傑) wrote: > Since you built it, you should be able to fire it up in a debugger > and see where it's dying. That's what I'd try first. More precisely: * Open chrome.xcodeproj * Make sure the "chrome" executable is active * Choose Run > Activate Breakpoints * Choose Run > Go —Jens --~--~-~--~~~---~--~~ 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: Problem in starting My Chromium on MacOSX
There may also be useful error messages in the error log (select "Console" from the "Run" menu in Xcode). --Amanda On Wed, Jul 15, 2009 at 6:50 PM, Albert J. Wong (王重傑) wrote: > Since you built it, you should be able to fire it up in a debugger and see > where it's dying. That's what I'd try first. > -A > > On Wed, Jul 15, 2009 at 3:47 PM, n179911 wrote: >> >> Hi, >> >> I download the source of chromium and build successfully on MacOSX. >> >> When I start the TestShell.app, it launches successfully and I can >> load a page (www.cnn.com) >> >> But when I start the Chromium.app, i see the Chromium appears on the >> Dock for 1-2 seconds and then it kills itself. >> >> Can you please tell me how can I get more information why my Chromium >> fails to launch? Or what am i missing to start my Chromium on Macos x. >> >> Thank you. >> >> p.s. Sorry for cross-posting. I couldn't get any help in >> chromium-discuss mailing list. >> >> > > > > > --~--~-~--~~~---~--~~ 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] Proposal: get extension views by type
On Wed, Jul 15, 2009 at 3:35 PM, Erik Kay wrote: > One quick question is about race conditions at load time. Will this handle > the case where a background page asks for its toolstrips right away (or vice > versa)? I think this is more an implementation issue, but you're right that we should specify the guarantee somewhere. I think that it should be that the background page lifetime bookends all other pages in an extension. This means that the backgound page will always exist when asked for, but there's no similar guarantee about toolstrips or whatever else. On Wed, Jul 15, 2009 at 3:46 PM, Matt Perry wrote: > nit: I'd prefer getTabs instead of getTabContents. Ok, I made that change. On Wed, Jul 15, 2009 at 3:48 PM, Matt Perry wrote: > Also, for most of our APIs, not specifying a windowId generally means "my > current window", while this means "all windows". It might be better to be > consistent with those APIs here. We could introduce a special windowId > constant like kAllWindows to satisfy the other case. Yeah, good point. I have updated it to also accept the string "all", which we can implement with JSON Schema, and which I think is a kinda elegant approach for doing constants in JS. WDYT? - 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] Proposal: get extension views by type
Also, for most of our APIs, not specifying a windowId generally means "my current window", while this means "all windows". It might be better to be consistent with those APIs here. We could introduce a special windowId constant like kAllWindows to satisfy the other case. On Wed, Jul 15, 2009 at 3:46 PM, Matt Perry wrote: > nit: I'd prefer getTabs instead of getTabContents. > > On Wed, Jul 15, 2009 at 12:41 PM, Aaron Boodman wrote: > >> >> We currently have the ability to get a list of references to all the >> DOMWindows in your own extension via chrome.extension.getViews(). >> >> But there have been requests to be able to get just the toolstrips, or >> just the background page. Additionally, I've heard requests for >> getting just the toolstrips associated with a particular window. >> >> Hence: >> http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/get-extension-views-by-type-proposal >> >> Feedback desired! >> >> - 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: Problem in starting My Chromium on MacOSX
Since you built it, you should be able to fire it up in a debugger and see where it's dying. That's what I'd try first. -A On Wed, Jul 15, 2009 at 3:47 PM, n179911 wrote: > > Hi, > > I download the source of chromium and build successfully on MacOSX. > > When I start the TestShell.app, it launches successfully and I can > load a page (www.cnn.com) > > But when I start the Chromium.app, i see the Chromium appears on the > Dock for 1-2 seconds and then it kills itself. > > Can you please tell me how can I get more information why my Chromium > fails to launch? Or what am i missing to start my Chromium on Macos x. > > Thank you. > > p.s. Sorry for cross-posting. I couldn't get any help in > chromium-discuss mailing list. > > > > --~--~-~--~~~---~--~~ 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] Notes on storing extension manifest in preferences
On Wed, Jul 15, 2009 at 3:20 PM, Aaron Boodman wrote: > On Wed, Jul 15, 2009 at 3:08 PM, Erik Kay wrote: > > On Wed, Jul 15, 2009 at 12:04 PM, Aaron Boodman wrote: > >> > >> On Wed, Jul 15, 2009 at 11:30 AM, Matt Perry > >> wrote: > >> > On Wed, Jul 15, 2009 at 9:59 AM, Aaron Boodman > wrote: > >> >> > >> >> a) I think it is important to not break the extension system with > this > >> >> mod, so that means that for awhile (1 or 2 dev channel releases?) we > >> >> will both write the entire manifest to the prefs and load from disk > >> >> normally. > >> > > >> > What if on extension load, we checked the prefs first, and if the > >> > manifest > >> > entry was absent, then we loaded from disk? New extension installs > >> > would > >> > write only to the pref. Seems like that would get us transparent > >> > backwards > >> > compat. > >> > >> You're right, that is another way to do it. > > > > +1 to Matt's approach here. > > On second thought, I don't like Matt's approach. It would require > writing lots of new, temporary, code to lazily load extensions, and to > wait for them to load before firing EXTENSIONS_READY. My original > suggestion, to just let loading carry on as it does today and to write > preferences when done would result in little new code. As we discussed offline, you guys are actually saying the same thing since today we only load extensions that are in prefs. So the only new point here is that we notice if the manifest isn't in prefs and then load it from disk and write it to prefs when we finish. > > Random wacky thought: perhaps validation could be done using JSON schema? > > (although it doesn't really fit in this case since this is running in > the > > browser) > > We really need a C++ implementation of JSON Schema to do that. It > isn't that hard, but I don't really have the motivation since we > already have the validation code. > Agree, that's why I called it a wacky thought. I guess if we found ourselves with a second wad of JSON like this it might make sense to implement it this way. Erik --~--~-~--~~~---~--~~ 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: Handling bad messages in the browser
On Jul 13, 1:57 pm, cpu wrote: > (hoping this does not generate a firestorm) > > If you are writing code that gets called from IPC_MESSAGE_HANDLER, in > other words you are writing or reviewing an IPC message handler, > please: > > 1- Consider the possibility of receiving a bad message (i.e a message > whose payload does not make sense, or is inconsistent) I just wanted to underline Carlos' point here with some reasons: 1) Obscure bugs or corruptions in the renderer often cause the renderer to send bad messages to the browser. This happens a lot when you scale out to tens of millions of users. It's nice if such a bug takes out only the tab and not the entire browser. 2) Because of Chrome's sandboxed renderer processes, it is a significant attack if a (compromised) renderer can confuse the browser by sending malformed or dangerous requests. If the browser's response to a malformed message is to corrupt memory, we currently issue "Critical" level security updates in response. Specific conditions to beware of include: - If your message includes any form of "length" or "count" or "size", make sure they are not negative or excessive. Impose a sane upper limit on any count before e.g. allocating resource based on it. - Behave gracefully if something expected is missing from the message. - Use very careful validation for messages which permit the renderer to request fundamentally dangerous things (e.g. access to files, installation of persistent extensions, etc). Cheers Chris > 2- When handling a bad message don't silently ignore it. > 3- When handling a bad message from another process, the most sane > path of action (when possible) is to call > process()->ReceivedBadMessage(); > > This is strongly recommended if you are handling messages coming from > a renderer. > > ReceivedBadMessage() current behavior is to terminate the offending > renderer (call BadMessageTerminateProcess()) > > BadMessageTerminateProcess() has DCHECK()s and LOG() stuff so if you > are calling ReceivedBadMessage() do not put them in your code. > > -cpu --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Problem in starting My Chromium on MacOSX
Hi, I download the source of chromium and build successfully on MacOSX. When I start the TestShell.app, it launches successfully and I can load a page (www.cnn.com) But when I start the Chromium.app, i see the Chromium appears on the Dock for 1-2 seconds and then it kills itself. Can you please tell me how can I get more information why my Chromium fails to launch? Or what am i missing to start my Chromium on Macos x. Thank you. p.s. Sorry for cross-posting. I couldn't get any help in chromium-discuss mailing list. --~--~-~--~~~---~--~~ 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] Proposal: get extension views by type
nit: I'd prefer getTabs instead of getTabContents. On Wed, Jul 15, 2009 at 12:41 PM, Aaron Boodman wrote: > > We currently have the ability to get a list of references to all the > DOMWindows in your own extension via chrome.extension.getViews(). > > But there have been requests to be able to get just the toolstrips, or > just the background page. Additionally, I've heard requests for > getting just the toolstrips associated with a particular window. > > Hence: > http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/get-extension-views-by-type-proposal > > Feedback desired! > > - 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] Proposal: get extension views by type
one more time On Wed, Jul 15, 2009 at 3:35 PM, Erik Kay wrote: > Very cool. > One quick question is about race conditions at load time. Will this handle > the case where a background page asks for its toolstrips right away (or vice > versa)? > > Erik > > > On Wed, Jul 15, 2009 at 12:41 PM, Aaron Boodman wrote: > >> >> We currently have the ability to get a list of references to all the >> DOMWindows in your own extension via chrome.extension.getViews(). >> >> But there have been requests to be able to get just the toolstrips, or >> just the background page. Additionally, I've heard requests for >> getting just the toolstrips associated with a particular window. >> >> Hence: >> http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/get-extension-views-by-type-proposal >> >> Feedback desired! >> >> - 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: Proposal: chrome.tabs.executeContentScript()
This is really great! One naming thought for you. I wonder if the methods should be named "loadScript" and "loadCSS"? I know that this is effectively the same thing with JS, but "execute" sounds like it's just running something temporarily (maybe in the page's context) and forgetting about it, while load is loading it into the page and leaving it there for later reference. I don't have a strong opinion about this, it's just what popped into my head. When you say no attempt is made to dedupe these, again it sounds like the only downside is that the code has been run twice. Even for transient code, the newly created context would stick around until the next GC, If the code did anything more substantial, it would also keep this context and extra memory alive. Perhaps this is just solved by stronger wording in the doc. Erik On Wed, Jul 15, 2009 at 12:37 PM, Aaron Boodman wrote: > > Thanks everyone for the quick feedback. I've modified the proposal to > support also executing strings of JavaScript. Detailed comments > inline. > > > On Wed, Jul 15, 2009 at 11:41 AM, Jói wrote: > > This seems very useful to me. > > Thanks! > > > On Wed, Jul 15, 2009 at 11:41 AM, Jói wrote: > > Perhaps it would be useful to also let extensions directly execute > > snippets of script, both for convenience and so that they don't need > > to be static files that are baked into the extension. You could > > imagine e.g. a content script that is dynamically generated based on > > preferences. > > On Wed, Jul 15, 2009 at 11:52 AM, Evan Martin wrote: > > Content to inject: > > What do I do if I have a string I'd like to inject? This may seem > > silly, but imagine you have a JS file that does most of the work and > > you'd like to do the equivalent of "var kDataToOperateOn = ...; > >
[chromium-dev] Re: Linux developers: you need to read this
On Wed, Jul 15, 2009 at 10:14 PM, Chris Evans wrote: > What will replace it and why? seccomp sandbox: * none of this admin crap * restricts the network * restricts access to worrying syscalls (vsplice etc) probably other reasons too. AGL --~--~-~--~~~---~--~~ 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] Notes on storing extension manifest in preferences
On Wed, Jul 15, 2009 at 3:08 PM, Erik Kay wrote: > On Wed, Jul 15, 2009 at 12:04 PM, Aaron Boodman wrote: >> >> On Wed, Jul 15, 2009 at 11:30 AM, Matt Perry >> wrote: >> > On Wed, Jul 15, 2009 at 9:59 AM, Aaron Boodman wrote: >> >> >> >> a) I think it is important to not break the extension system with this >> >> mod, so that means that for awhile (1 or 2 dev channel releases?) we >> >> will both write the entire manifest to the prefs and load from disk >> >> normally. >> > >> > What if on extension load, we checked the prefs first, and if the >> > manifest >> > entry was absent, then we loaded from disk? New extension installs >> > would >> > write only to the pref. Seems like that would get us transparent >> > backwards >> > compat. >> >> You're right, that is another way to do it. > > +1 to Matt's approach here. On second thought, I don't like Matt's approach. It would require writing lots of new, temporary, code to lazily load extensions, and to wait for them to load before firing EXTENSIONS_READY. My original suggestion, to just let loading carry on as it does today and to write preferences when done would result in little new code. > Random wacky thought: perhaps validation could be done using JSON schema? > (although it doesn't really fit in this case since this is running in the > browser) We really need a C++ implementation of JSON Schema to do that. It isn't that hard, but I don't really have the motivation since we already have the validation code. - 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: Linux developers: you need to read this
On Jul 14, 7:26 pm, Adam Langley wrote: > On Tue, Jul 14, 2009 at 7:18 PM, Jeremy Orlow wrote: > > Wait...so is this something every linux Chromium developer is going to have > > to do forever? > > You only need to do it once and, if you don't, you just run without a sandbox. > > Also, the SUID sandbox will probably not be around forever (maybe not > even for the next couple of months). What will replace it and why? Cheers Chris > > I'm open to suggestions about how else to handle this if you have any, > > AGL --~--~-~--~~~---~--~~ 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] Notes on storing extension manifest in preferences
resending On Wed, Jul 15, 2009 at 3:08 PM, Erik Kay wrote: > On Wed, Jul 15, 2009 at 12:04 PM, Aaron Boodman wrote: > >> >> On Wed, Jul 15, 2009 at 11:30 AM, Matt Perry >> wrote: >> > On Wed, Jul 15, 2009 at 9:59 AM, Aaron Boodman wrote: >> >> >> >> a) I think it is important to not break the extension system with this >> >> mod, so that means that for awhile (1 or 2 dev channel releases?) we >> >> will both write the entire manifest to the prefs and load from disk >> >> normally. >> > >> > What if on extension load, we checked the prefs first, and if the >> manifest >> > entry was absent, then we loaded from disk? New extension installs >> would >> > write only to the pref. Seems like that would get us transparent >> backwards >> > compat. >> >> You're right, that is another way to do it. > > > +1 to Matt's approach here. > > > >> b) Extension prefs are currently written in >> >> ExtensionsService::OnExtensionInstalled. At this point, we no longer >> >> have the JSON form of the manifest, it has already been parsed into an >> >> Extension object. >> > >> > It's easy enough to pass along the JSON object from OnExtensionUnpacked, >> > which calls OnExtensionInstalled. >> >> True, but it felt really messy to me. Basically this means that we end >> up with two representations of the extension: the Extension manifest >> and the Extension object. The object contains all kinds of extra state >> like the location, the path, etc. It seems like an area for potential >> confusion. >> >> >> b) and c) lead me to the conclusion that we should refactor the >> >> Extension class so that it is a lightweight wrapper around a JSON >> >> dictionary and has no state of its own. This would fix the problem of >> >> not having access to the JSON representation and therefore having to >> >> write serialization code for it. >> > >> > A less radical approach would be to keep a copy of the JSON dictionary >> in >> > the Extension class while we're in this migration period. That's not to >> say >> > we shouldn't refactor the Extension class (I have no opinion on that). >> >> True. > > > Refactoring Extension to be a light-weight wrapper around DictionaryValue > seems reasonable. It's somewhat annoying that every time someone wants a > property that the code will need to go through all of the (if has key, get > key) work (potentially through multiple levels of hierarchy), but I don't > think that there's a practical downside (we don't ask for properties very > often). It also means that we'll wind up duplicating a fair amount of code > between validation and access, but again I don't see this as a huge problem > either. > > Random wacky thought: perhaps validation could be done using JSON schema? > (although it doesn't really fit in this case since this is running in the > browser) > > Erik > > --~--~-~--~~~---~--~~ 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: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 12:57 PM, Peter Kasting wrote: > This is my concern. A number of WebKit things at least used to only work > with a Cygwin SVN checkout. > Sadly, it looks as if this is still the case. Using Adam's instructions on Windows results in a WebKit checkout where scripts like build-webkit do not work. I'm not sure how to fix the underlying issues here, so I suggest Windows WebKit hackers should probably keep a separate checkout. If anyone knows scripting stuff well enough to help fix the scripts, I would very much welcome that help. 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: Hacking on WebKit is easier than ever
> These instructions turn src/third_party/WebKit into a full-fledged WebKit checkout Hallelujah... thank you for writing this up! --~--~-~--~~~---~--~~ 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: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 1:55 PM, Adam Barth wrote: > On Wed, Jul 15, 2009 at 1:53 PM, Peter Kasting wrote: >> On Wed, Jul 15, 2009 at 1:45 PM, Adam Barth wrote: >>> >>> Maybe try removing those directories from your .gclient_entries file? >> >> This fixed things. Updated the directions. Also noted that people should >> still run update-webkit at least once (for the WebKitLibraries install >> step). > > I'll update the instructions with these two points. Looks like you beat me to it. :) Adam --~--~-~--~~~---~--~~ 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: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 1:53 PM, Peter Kasting wrote: > On Wed, Jul 15, 2009 at 1:45 PM, Adam Barth wrote: >> >> Maybe try removing those directories from your .gclient_entries file? > > This fixed things. Updated the directions. Also noted that people should > still run update-webkit at least once (for the WebKitLibraries install > step). I'll update the instructions with these two points. Adam --~--~-~--~~~---~--~~ 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: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 1:45 PM, Adam Barth wrote: > > On Wed, Jul 15, 2009 at 1:40 PM, Peter Kasting > wrote: > > On Wed, Jul 15, 2009 at 1:34 PM, Adam Barth wrote: > >> > >> On Wed, Jul 15, 2009 at 12:57 PM, Peter Kasting > >> wrote: > >> > I am still confused. > >> > >> I recommend the experimental method. If you have trouble, we can try > >> to figure out what's different between your setup and my setup. > > > > OK, first problem: I get the following warning spew after every gclient > > sync: > > WARNING: "src/third_party/WebKit/WebCore" is no longer part of this > client. > > It > > is recommended that you manually remove it. > > WARNING: "src/third_party/WebKit/JavaScriptCore" is no longer part of > this > > client. It is recommended that you manually remove it. > > WARNING: "src/third_party/WebKit/LayoutTests" is no longer part of this > > client. > > It is recommended that you manually remove it. > > No matter what I do (resync, delete these directories and resync, etc.) I > > still get these warnings. > > This sounds like a recent change to gclient. The old behavior was > that gclient would delete these directories during the first sync > (because it decided they were no longer needed). The second sync > would then pull them in from svn.webkit.org. > > Maybe try removing those directories from your .gclient_entries file? > > Adam > > > > gclient is not smart enough to handle this case. manual cleanup is required. -darin --~--~-~--~~~---~--~~ 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: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 1:45 PM, Adam Barth wrote: > Maybe try removing those directories from your .gclient_entries file? > This fixed things. Updated the directions. Also noted that people should still run update-webkit at least once (for the WebKitLibraries install step). 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: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 1:45 PM, Adam Barth wrote: > > On Wed, Jul 15, 2009 at 1:40 PM, Peter Kasting > wrote: > > On Wed, Jul 15, 2009 at 1:34 PM, Adam Barth wrote: > >> > >> On Wed, Jul 15, 2009 at 12:57 PM, Peter Kasting > >> wrote: > >> > I am still confused. > >> > >> I recommend the experimental method. If you have trouble, we can try > >> to figure out what's different between your setup and my setup. > > > > OK, first problem: I get the following warning spew after every gclient > > sync: > > WARNING: "src/third_party/WebKit/WebCore" is no longer part of this > client. > > It > > is recommended that you manually remove it. > > WARNING: "src/third_party/WebKit/JavaScriptCore" is no longer part of > this > > client. It is recommended that you manually remove it. > > WARNING: "src/third_party/WebKit/LayoutTests" is no longer part of this > > client. > > It is recommended that you manually remove it. > > No matter what I do (resync, delete these directories and resync, etc.) I > > still get these warnings. > > This sounds like a recent change to gclient. The old behavior was > that gclient would delete these directories during the first sync > (because it decided they were no longer needed). The second sync > would then pull them in from svn.webkit.org. > > Maybe try removing those directories from your .gclient_entries file? I actually added that change to keep gclient from deleting subdirectories underneath a git controlled webkit checkout. The old behavior is available if you specified the --delete_unversioned_trees option. -Albert --~--~-~--~~~---~--~~ 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: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 1:40 PM, Peter Kasting wrote: > On Wed, Jul 15, 2009 at 1:34 PM, Adam Barth wrote: >> >> On Wed, Jul 15, 2009 at 12:57 PM, Peter Kasting >> wrote: >> > I am still confused. >> >> I recommend the experimental method. If you have trouble, we can try >> to figure out what's different between your setup and my setup. > > OK, first problem: I get the following warning spew after every gclient > sync: > WARNING: "src/third_party/WebKit/WebCore" is no longer part of this client. > It > is recommended that you manually remove it. > WARNING: "src/third_party/WebKit/JavaScriptCore" is no longer part of this > client. It is recommended that you manually remove it. > WARNING: "src/third_party/WebKit/LayoutTests" is no longer part of this > client. > It is recommended that you manually remove it. > No matter what I do (resync, delete these directories and resync, etc.) I > still get these warnings. I finally found the trick that works for me for these sorts of things: 1) delete the directories 2) delete .gclient_entries 3) resync --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 1:40 PM, Peter Kasting wrote: > On Wed, Jul 15, 2009 at 1:34 PM, Adam Barth wrote: >> >> On Wed, Jul 15, 2009 at 12:57 PM, Peter Kasting >> wrote: >> > I am still confused. >> >> I recommend the experimental method. If you have trouble, we can try >> to figure out what's different between your setup and my setup. > > OK, first problem: I get the following warning spew after every gclient > sync: > WARNING: "src/third_party/WebKit/WebCore" is no longer part of this client. > It > is recommended that you manually remove it. > WARNING: "src/third_party/WebKit/JavaScriptCore" is no longer part of this > client. It is recommended that you manually remove it. > WARNING: "src/third_party/WebKit/LayoutTests" is no longer part of this > client. > It is recommended that you manually remove it. > No matter what I do (resync, delete these directories and resync, etc.) I > still get these warnings. This sounds like a recent change to gclient. The old behavior was that gclient would delete these directories during the first sync (because it decided they were no longer needed). The second sync would then pull them in from svn.webkit.org. Maybe try removing those directories from your .gclient_entries file? Adam --~--~-~--~~~---~--~~ 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: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 1:34 PM, Adam Barth wrote: > On Wed, Jul 15, 2009 at 12:57 PM, Peter Kasting > wrote: > > I am still confused. > > I recommend the experimental method. If you have trouble, we can try > to figure out what's different between your setup and my setup. OK, first problem: I get the following warning spew after every gclient sync: WARNING: "src/third_party/WebKit/WebCore" is no longer part of this client. It is recommended that you manually remove it. WARNING: "src/third_party/WebKit/JavaScriptCore" is no longer part of this client. It is recommended that you manually remove it. WARNING: "src/third_party/WebKit/LayoutTests" is no longer part of this client. It is recommended that you manually remove it. No matter what I do (resync, delete these directories and resync, etc.) I still get these warnings. 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: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 12:57 PM, Peter Kasting wrote: > I am still confused. I recommend the experimental method. If you have trouble, we can try to figure out what's different between your setup and my setup. Adam --~--~-~--~~~---~--~~ 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: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 12:50 PM, Adam Barth wrote: > I think gclient uses the depot_tools one to update the files, but the > WebKitTools/Scripts use the svn in your path (for me, the Cygwin one) > for svn status, diff, commit, etc. Yes, this is true. This is why I was asking. It might be key to have these be > the same version of SVN. If they aren't at least compatible SVN versions, then if you update the files in third_party/webkit via a gclient sync, you won't be able to use "update-webkit" in there to update (it will complain about the checkout being too new). For a while, I was using the depot_tools SVN in my path. That worked > decently well once I fixed all the scripts to understand different > line endings. The one thing that I couldn't get to work right was the > commit-log-editor, so I switched to Cygwin SVN and have been happy > ever since. This is my concern. A number of WebKit things at least used to only work with a Cygwin SVN checkout. Even if that's no longer true, and a checkout via gclient can now build, if it still requires a Cygwin SVN to run commit-log-editor properly then I can't check in easily :( If gclient just shelled off to update-webkit to update the webkit directory, then all things would just work fine. I am still confused. 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: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 12:44 PM, Peter Kasting wrote: > On Wed, Jul 15, 2009 at 12:39 PM, Adam Barth wrote: >> Thanks to some recent work by Dimitri, Victor, and others, hacking on >> WebKit is now easier than ever. If you work on WebKit and Chromium, I >> recommend using a hybrid source tree: >> >> http://dev.chromium.org/developers/contributing-to-webkit > > How do you use the Cygwin SVN for the WebKit parts of this checkout (like > you said you were doing) and the depot_tools one for the rest, when the > WebKit checkout is controlled by gclient? I have no idea, but it works. I think gclient uses the depot_tools one to update the files, but the WebKitTools/Scripts use the svn in your path (for me, the Cygwin one) for svn status, diff, commit, etc. It might be key to have these be the same version of SVN. For a while, I was using the depot_tools SVN in my path. That worked decently well once I fixed all the scripts to understand different line endings. The one thing that I couldn't get to work right was the commit-log-editor, so I switched to Cygwin SVN and have been happy ever since. Adam --~--~-~--~~~---~--~~ 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: Hacking on WebKit is easier than ever
On Wed, Jul 15, 2009 at 12:39 PM, Adam Barth wrote: > Thanks to some recent work by Dimitri, Victor, and others, hacking on > WebKit is now easier than ever. If you work on WebKit and Chromium, I > recommend using a hybrid source tree: > > http://dev.chromium.org/developers/contributing-to-webkit > How do you use the Cygwin SVN for the WebKit parts of this checkout (like you said you were doing) and the depot_tools one for the rest, when the WebKit checkout is controlled by gclient? 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] [extensions] Proposal: get extension views by type
We currently have the ability to get a list of references to all the DOMWindows in your own extension via chrome.extension.getViews(). But there have been requests to be able to get just the toolstrips, or just the background page. Additionally, I've heard requests for getting just the toolstrips associated with a particular window. Hence: http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/get-extension-views-by-type-proposal Feedback desired! - 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] Hacking on WebKit is easier than ever
Thanks to some recent work by Dimitri, Victor, and others, hacking on WebKit is now easier than ever. If you work on WebKit and Chromium, I recommend using a hybrid source tree: http://dev.chromium.org/developers/contributing-to-webkit These instructions turn src/third_party/WebKit into a full-fledged WebKit checkout, which you can use exactly like any other WebKit checkout with the added bonus that it compiles into Chromium. I've been dogfooding this setup for a while, and it seems to work pretty well. Enjoy! Adam --~--~-~--~~~---~--~~ 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: Proposal: chrome.tabs.executeContentScript()
Thanks everyone for the quick feedback. I've modified the proposal to support also executing strings of JavaScript. Detailed comments inline. On Wed, Jul 15, 2009 at 11:41 AM, Jói wrote: > This seems very useful to me. Thanks! On Wed, Jul 15, 2009 at 11:41 AM, Jói wrote: > Perhaps it would be useful to also let extensions directly execute > snippets of script, both for convenience and so that they don't need > to be static files that are baked into the extension. You could > imagine e.g. a content script that is dynamically generated based on > preferences. On Wed, Jul 15, 2009 at 11:52 AM, Evan Martin wrote: > Content to inject: > What do I do if I have a string I'd like to inject? This may seem > silly, but imagine you have a JS file that does most of the work and > you'd like to do the equivalent of "var kDataToOperateOn = ...; >
[chromium-dev] Re: [extensions] Notes on storing extension manifest in preferences
On Wed, Jul 15, 2009 at 11:30 AM, Matt Perry wrote: > On Wed, Jul 15, 2009 at 9:59 AM, Aaron Boodman wrote: >> >> a) I think it is important to not break the extension system with this >> mod, so that means that for awhile (1 or 2 dev channel releases?) we >> will both write the entire manifest to the prefs and load from disk >> normally. > > What if on extension load, we checked the prefs first, and if the manifest > entry was absent, then we loaded from disk? New extension installs would > write only to the pref. Seems like that would get us transparent backwards > compat. You're right, that is another way to do it. >> b) Extension prefs are currently written in >> ExtensionsService::OnExtensionInstalled. At this point, we no longer >> have the JSON form of the manifest, it has already been parsed into an >> Extension object. > > It's easy enough to pass along the JSON object from OnExtensionUnpacked, > which calls OnExtensionInstalled. True, but it felt really messy to me. Basically this means that we end up with two representations of the extension: the Extension manifest and the Extension object. The object contains all kinds of extra state like the location, the path, etc. It seems like an area for potential confusion. >> b) and c) lead me to the conclusion that we should refactor the >> Extension class so that it is a lightweight wrapper around a JSON >> dictionary and has no state of its own. This would fix the problem of >> not having access to the JSON representation and therefore having to >> write serialization code for it. > > A less radical approach would be to keep a copy of the JSON dictionary in > the Extension class while we're in this migration period. That's not to say > we shouldn't refactor the Extension class (I have no opinion on that). True. - 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] Proposal: chrome.tabs.executeContentScript()
Frames: [we talked in person, but to summarize] This won't allow injection into subframes that are not of the same origin as the outermost frame. This is maybe too small a use case to worry about for now, but it's good to at least call it out. Content to inject: What do I do if I have a string I'd like to inject? This may seem silly, but imagine you have a JS file that does most of the work and you'd like to do the equivalent of "var kDataToOperateOn = ...;
[chromium-dev] Re: Proposal: chrome.tabs.executeContentScript()
One pie-in-the-sky idea I have is to pre-compile content scripts. Restricting the API to static JS files would allow us to do such a thing. On Wed, Jul 15, 2009 at 11:41 AM, Jói wrote: > > This seems very useful to me. > > Perhaps it would be useful to also let extensions directly execute > snippets of script, both for convenience and so that they don't need > to be static files that are baked into the extension. You could > imagine e.g. a content script that is dynamically generated based on > preferences. > > Cheers, > Jói > > > On Jul 15, 2:26 pm, Aaron Boodman wrote: > > On Wed, Jul 15, 2009 at 11:22 AM, Aaron Boodman > wrote: > > > Hence: > http://sites.google.com/a/chromium.org/dev/developers/design-document... > > > > Typo. Should have been: > http://sites.google.com/a/chromium.org/dev/developers/design-document... > > > > - 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: Proposal: chrome.tabs.executeContentScript()
This seems very useful to me. Perhaps it would be useful to also let extensions directly execute snippets of script, both for convenience and so that they don't need to be static files that are baked into the extension. You could imagine e.g. a content script that is dynamically generated based on preferences. Cheers, Jói On Jul 15, 2:26 pm, Aaron Boodman wrote: > On Wed, Jul 15, 2009 at 11:22 AM, Aaron Boodman wrote: > > Hence:http://sites.google.com/a/chromium.org/dev/developers/design-document... > > Typo. Should have > been:http://sites.google.com/a/chromium.org/dev/developers/design-document... > > - 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] Proposal: chrome.tabs.executeContentScript()
On Wed, Jul 15, 2009 at 11:22 AM, Aaron Boodman wrote: > Hence: > http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/executecontentscript-propoal Typo. Should have been: http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/executecontentscript-proposal - 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] Notes on storing extension manifest in preferences
On Wed, Jul 15, 2009 at 9:59 AM, Aaron Boodman wrote: > a) I think it is important to not break the extension system with this > mod, so that means that for awhile (1 or 2 dev channel releases?) we > will both write the entire manifest to the prefs and load from disk > normally. What if on extension load, we checked the prefs first, and if the manifest entry was absent, then we loaded from disk? New extension installs would write only to the pref. Seems like that would get us transparent backwards compat. > b) Extension prefs are currently written in > ExtensionsService::OnExtensionInstalled. At this point, we no longer > have the JSON form of the manifest, it has already been parsed into an > Extension object. It's easy enough to pass along the JSON object from OnExtensionUnpacked, which calls OnExtensionInstalled. b) and c) lead me to the conclusion that we should refactor the > Extension class so that it is a lightweight wrapper around a JSON > dictionary and has no state of its own. This would fix the problem of > not having access to the JSON representation and therefore having to > write serialization code for it. A less radical approach would be to keep a copy of the JSON dictionary in the Extension class while we're in this migration period. That's not to say we shouldn't refactor the Extension class (I have no opinion on that). --~--~-~--~~~---~--~~ 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] Proposal: chrome.tabs.executeContentScript()
Multiple developers have asked for a way to execute content scripts programmatically, and it seems reasonable enough. Hence: http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/executecontentscript-propoal Comments desired. - 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: Linux developers: you need to read this
On Wed, Jul 15, 2009 at 5:07 PM, Michael wrote: > Ah... sure! > > Still wondering if this is working as intended... ps shows me: Zombies not intended, but it's not reducing the browser to an unworkable mess either so it's behind the bugs which are. Cheers AGL --~--~-~--~~~---~--~~ 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: Linux developers: you need to read this
On Jul 15, 4:51 pm, Adam Langley wrote: > * re-GYP: cd .. && ./depot_tools/gclient runhooks --force && cd src > should probably do it. Ah... sure! Still wondering if this is working as intended... ps shows me: 28704 pts/2Z+ 0:00 [chrome-devel-sa] 28706 pts/2Z+ 0:00 [chrome-devel-sa] --~--~-~--~~~---~--~~ 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] Notes on storing extension manifest in preferences
I looked yesterday at storing the entire extension state, including its manifest in the preferences. This is desirable because it will reduce disk IO at startup and eliminate some kinds of races that we have today. I decided not to do this now because it ended up being orthogonal to the feature I'm working on, but I wanted to write down what I came up with in case someone else gets to it before me. a) I think it is important to not break the extension system with this mod, so that means that for awhile (1 or 2 dev channel releases?) we will both write the entire manifest to the prefs and load from disk normally. b) Extension prefs are currently written in ExtensionsService::OnExtensionInstalled. At this point, we no longer have the JSON form of the manifest, it has already been parsed into an Extension object. c) In order to avoid breaking backward compat, we also need to write the prefs at ExtensionsService::OnExtensionsLoaded. At this point, we also do not have the JSON anymore, only Extension objects. b) and c) lead me to the conclusion that we should refactor the Extension class so that it is a lightweight wrapper around a JSON dictionary and has no state of its own. This would fix the problem of not having access to the JSON representation and therefore having to write serialization code for it. At the same time we could decouple validation from the Extension class into an ExtensionManifestValidator thing. The contents of the manifest have at this point diverged pretty far from the static state of an extension post-installation and I think they should be separate concerns. Thoughts? - 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: Themes and their removal
> You should look at what the windows impl does. It probably goes > directly to the themes system and tells it to reset, without involving > extensions. That's right, it calls BrowserThemeProvider::UseDefaultTheme > Glen, now that we have extension uninstall implemented, I feel like we > should integrate these two better. There should be (low-priority) > todos for: > > * On theme switch, uninstall any previous theme extension > * On extension uninstall, if it is a theme, revert to the default theme > * In the prefs pane, call ExtnesionsService::UninstallExtension() > instead of whatever we're currently doing I agree - we definitely need these post-3.0 --~--~-~--~~~---~--~~ 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: Linux developers: you need to read this
On Wed, Jul 15, 2009 at 2:11 AM, Adam Langley wrote: > * Edit build/common.gypi and change linux_suid_sandbox_restrictions > from "Path" to "User" (missed a step) * re-GYP: cd .. && ./depot_tools/gclient runhooks --force && cd src should probably do it. AGL --~--~-~--~~~---~--~~ 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
You should look at what the windows impl does. It probably goes directly to the themes system and tells it to reset, without involving extensions. However Glen, now that we have extension uninstall implemented, I feel like we should integrate these two better. There should be (low-priority) todos for: * On theme switch, uninstall any previous theme extension * On extension uninstall, if it is a theme, revert to the default theme * In the prefs pane, call ExtnesionsService::UninstallExtension() instead of whatever we're currently doing - a On Wed, Jul 15, 2009 at 9:16 AM, Avi Drissman wrote: > 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: Linux developers: you need to read this
Oh... I am building Release configuration, maybe this is not yet working there? --~--~-~--~~~---~--~~ 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: Linux developers: you need to read this
On Jul 15, 6:31 pm, Adam Langley wrote: > Please make sure that you sync >= 20718. As Joel pointed out, I typoed > a #define. > > AGL Sure... svn info | grep Revision Revision: 20728 --~--~-~--~~~---~--~~ 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: Linux developers: you need to read this
On Wed, Jul 15, 2009 at 4:21 PM, Michael wrote: > It's correctly set to User and I have since done a complete clean > rebuild of the tree, still no joy... Please make sure that you sync >= 20718. As Joel pointed out, I typoed a #define. AGL --~--~-~--~~~---~--~~ 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: Linux developers: you need to read this
I the sandbox like mentioned above but it doesn't seem to work for me: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking This wrapper can only run /opt/google/chrome/chrome! If you are developing Chrome, you should read: http://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopment It's correctly set to User and I have since done a complete clean rebuild of the tree, still no joy... --~--~-~--~~~---~--~~ 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
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
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: FYI is hosed
I cc'd vlad.-Darin On Wed, Jul 15, 2009 at 4:00 AM, Dean McNamee wrote: > > If anyone out there from Mozilla is reading, or someone knows where to > redirect this bug, that would be really helpful: > > https://bugzilla.mozilla.org/show_bug.cgi?id=504301 > > Thanks > > On Tue, Jul 14, 2009 at 8:23 PM, Dean McNamee wrote: > > My point was the behavior before the patch was wrong. What they did > > now is closer, but still wrong. > > > > On Tue, Jul 14, 2009 at 8:22 PM, Peter Kasting > wrote: > >> On Tue, Jul 14, 2009 at 11:15 AM, Dean McNamee > wrote: > >>> > >>> We weren't spec compliant: > >>> > >>> http://dev.w3.org/html5/spec/Overview.html > >>> > >>> The lineTo(x, y) method must do nothing if the context has no subpaths. > >> > >> Isn't that what I just said? That the current behavior doesn't match > the > >> spec? > >> I still don't understand what's going on or what chromium-dev should do > >> about it. > >> 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: Themes and their removal
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
On Wed, Jul 15, 2009 at 7:44 AM, Avi Drissman wrote: > 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 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? 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). I assume you're talking about uninstalling the theme from chrome://extensions. This sounds like a straightforward bug. We should just invoke the "reset to default theme" code when we uninstall the current 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? How do we want to go with this? I'd file a bug for the second, but punt on the first. Erik --~--~-~--~~~---~--~~ 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
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: Creating a Custom View
dev.chromium.org has a lot of info ("Getting around the source code" is an
example).But in your case, you want it to start up without switches, you
just want it to be your version from the beginning with no special attention
(besides compiling).
You cannot exactly 'upload the changes back to the Google servers', you can
submit a patch that will incorporate your changes (little changes, do not
bring up all of the changes because people review these patches), there is
an explanation about this in dev.chromium.org too.
One (or more) of the committers review your changes and if the changes were
approved, they commit the change list (=patch).
Before submitting a patch, you should first ask if this is possible, because
maybe they are not ready for supporting multiple (external) branches yet.
SVN should be fine about the changes, anyway, unless there are real
conflicts.
Just run "gclient sync" and everything will be fine (and if not, it will
notify you with a confirmation and some options).
About the switches, you can simply reverse the switch (with ! in the
condition). But that will also give you the incognito features, which I am
not sure you would really like to have.
☆PhistucK
On Wed, Jul 15, 2009 at 13:33, Kruncher wrote:
>
> I wasn't aware that SVN manages changes within the content of a file.
> I am relatively new to open source code, and have only ever used SVN
> to download the Chromium trunk. I also did not realize that it was
> possible to upload changes back to the Google servers.
>
> I will have to read up on how SVN works. Perhaps there is a reserved
> comment/macro that can be used to protect a range of code.
>
> Across several of the projects there appears to be an interface which
> is responsible for constructing the required browser based upon
> command switches. This interface is able to switch between starting up
> with the standard and incognito windows, so I thought perhaps there
> would be a way to override this.
>
> Do you know of any documentation which explains the architecture of
> Chromium, and the purpose of the various projects and files?
>
> On 15 July, 10:41, PhistucK wrote:
> > SVN usually manages to merge the changes you have made with the changes
> from
> > trunk, unless they have changed that same bit of code you have and then,
> it
> > says there is a conflict and lets you look at the differences. I modified
> > things in the actual Chromium source, not in a new project.
> >
> > There was a thread about creating branches and they said it is better
> > handled with GIT, though I have never used GIT and since almost all of my
> > changes were only adding things\the code nearby the code I changes were
> not
> > changed, no conflicts occurred.
> >
> > If your changes can be incorporated into the code because most of what
> they
> > do is removing options, maybe you can even upload your changes to the
> > Chromium source code (with #IF DEFINE YOUR_CUSTOM_CODE or something). But
> > you have to ask them first, of course.
> >
> > ☆PhistucK
> >
> >
> >
> > On Wed, Jul 15, 2009 at 11:41, Kruncher wrote:
> >
> > > Thanks for your fast reply!
> >
> > > When you made your changes, did you start with a new project, or did
> > > you edit the Chromium browser itself?
> >
> > > I was considering just modifying the browser. My concern was that if I
> > > wanted to update the Chromium trunk, I would need to redo my various
> > > changes to the system.
> >
> > > Thanks again,
> >
> > > On 15 July, 09:31, PhistucK wrote:
> > > > It is actually pretty easy to do that, I guess.I changed chromium to
> > > support
> > > > another button in the toolbar with a keyboard shortcut and removed
> the
> > > > "About Chromium" menu really easily - and my knowledge in C++ is
> nearly
> > > > nonexistent (I only know the syntax since it is similar to
> JavaScript).
> >
> > > > You should look at the code that uses the regular window and the code
> > > that
> > > > uses the incognito window (use the theme GRD files for hints to what
> to
> > > > search for, like the Incognito logo and its ID) and compare the two,
> move
> > > > the things that fit you from incognito back into the regular window.
> > > > The debugger and everything, you can leave them in the code, simply
> > > remove
> > > > all of the reference to them, like menu items (pretty easy to find),
> > > > keyboard shortcuts and context menu items.
> >
> > > > ☆PhistucK
> >
> > > > On Wed, Jul 15, 2009 at 10:50, Kruncher wrote:
> >
> > > > > Hi,
> >
> > > > > I would like to create a custom browser application based on the
> > > > > Chromium source. I have downloaded and compiled the source (from
> the
> > > > > "Chrome.sln" solution.
> >
> > > > > What I want to do is:
> > > > > - Create a new executable project.
> > > > > - Create a custom view that is similar to the "Incognito" view. I
> > > > > would like the browser to start in this view when opened.
> >
> > > > > However, I do not want/need to include the regular or "Incognito"
> >
[chromium-dev] Re: FYI is hosed
If anyone out there from Mozilla is reading, or someone knows where to redirect this bug, that would be really helpful: https://bugzilla.mozilla.org/show_bug.cgi?id=504301 Thanks On Tue, Jul 14, 2009 at 8:23 PM, Dean McNamee wrote: > My point was the behavior before the patch was wrong. What they did > now is closer, but still wrong. > > On Tue, Jul 14, 2009 at 8:22 PM, Peter Kasting wrote: >> On Tue, Jul 14, 2009 at 11:15 AM, Dean McNamee wrote: >>> >>> We weren't spec compliant: >>> >>> http://dev.w3.org/html5/spec/Overview.html >>> >>> The lineTo(x, y) method must do nothing if the context has no subpaths. >> >> Isn't that what I just said? That the current behavior doesn't match the >> spec? >> I still don't understand what's going on or what chromium-dev should do >> about it. >> 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: Creating a Custom View
I wasn't aware that SVN manages changes within the content of a file. I am relatively new to open source code, and have only ever used SVN to download the Chromium trunk. I also did not realize that it was possible to upload changes back to the Google servers. I will have to read up on how SVN works. Perhaps there is a reserved comment/macro that can be used to protect a range of code. Across several of the projects there appears to be an interface which is responsible for constructing the required browser based upon command switches. This interface is able to switch between starting up with the standard and incognito windows, so I thought perhaps there would be a way to override this. Do you know of any documentation which explains the architecture of Chromium, and the purpose of the various projects and files? On 15 July, 10:41, PhistucK wrote: > SVN usually manages to merge the changes you have made with the changes from > trunk, unless they have changed that same bit of code you have and then, it > says there is a conflict and lets you look at the differences. I modified > things in the actual Chromium source, not in a new project. > > There was a thread about creating branches and they said it is better > handled with GIT, though I have never used GIT and since almost all of my > changes were only adding things\the code nearby the code I changes were not > changed, no conflicts occurred. > > If your changes can be incorporated into the code because most of what they > do is removing options, maybe you can even upload your changes to the > Chromium source code (with #IF DEFINE YOUR_CUSTOM_CODE or something). But > you have to ask them first, of course. > > ☆PhistucK > > > > On Wed, Jul 15, 2009 at 11:41, Kruncher wrote: > > > Thanks for your fast reply! > > > When you made your changes, did you start with a new project, or did > > you edit the Chromium browser itself? > > > I was considering just modifying the browser. My concern was that if I > > wanted to update the Chromium trunk, I would need to redo my various > > changes to the system. > > > Thanks again, > > > On 15 July, 09:31, PhistucK wrote: > > > It is actually pretty easy to do that, I guess.I changed chromium to > > support > > > another button in the toolbar with a keyboard shortcut and removed the > > > "About Chromium" menu really easily - and my knowledge in C++ is nearly > > > nonexistent (I only know the syntax since it is similar to JavaScript). > > > > You should look at the code that uses the regular window and the code > > that > > > uses the incognito window (use the theme GRD files for hints to what to > > > search for, like the Incognito logo and its ID) and compare the two, move > > > the things that fit you from incognito back into the regular window. > > > The debugger and everything, you can leave them in the code, simply > > remove > > > all of the reference to them, like menu items (pretty easy to find), > > > keyboard shortcuts and context menu items. > > > > ☆PhistucK > > > > On Wed, Jul 15, 2009 at 10:50, Kruncher wrote: > > > > > Hi, > > > > > I would like to create a custom browser application based on the > > > > Chromium source. I have downloaded and compiled the source (from the > > > > "Chrome.sln" solution. > > > > > What I want to do is: > > > > - Create a new executable project. > > > > - Create a custom view that is similar to the "Incognito" view. I > > > > would like the browser to start in this view when opened. > > > > > However, I do not want/need to include the regular or "Incognito" > > > > views, and I want to strip out all of the JavaScript/DOM debugging > > > > parts. > > > > > I would really appreciate it if someone could give me some guidelines. > > > > I have had a read through some of the sources, and I have a rough idea > > > > as to how the projects are structured. > > > > > Many thanks, > > > > Lea Hayes --~--~-~--~~~---~--~~ 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: Creating a Custom View
SVN usually manages to merge the changes you have made with the changes from trunk, unless they have changed that same bit of code you have and then, it says there is a conflict and lets you look at the differences. I modified things in the actual Chromium source, not in a new project. There was a thread about creating branches and they said it is better handled with GIT, though I have never used GIT and since almost all of my changes were only adding things\the code nearby the code I changes were not changed, no conflicts occurred. If your changes can be incorporated into the code because most of what they do is removing options, maybe you can even upload your changes to the Chromium source code (with #IF DEFINE YOUR_CUSTOM_CODE or something). But you have to ask them first, of course. ☆PhistucK On Wed, Jul 15, 2009 at 11:41, Kruncher wrote: > > Thanks for your fast reply! > > When you made your changes, did you start with a new project, or did > you edit the Chromium browser itself? > > I was considering just modifying the browser. My concern was that if I > wanted to update the Chromium trunk, I would need to redo my various > changes to the system. > > Thanks again, > > On 15 July, 09:31, PhistucK wrote: > > It is actually pretty easy to do that, I guess.I changed chromium to > support > > another button in the toolbar with a keyboard shortcut and removed the > > "About Chromium" menu really easily - and my knowledge in C++ is nearly > > nonexistent (I only know the syntax since it is similar to JavaScript). > > > > You should look at the code that uses the regular window and the code > that > > uses the incognito window (use the theme GRD files for hints to what to > > search for, like the Incognito logo and its ID) and compare the two, move > > the things that fit you from incognito back into the regular window. > > The debugger and everything, you can leave them in the code, simply > remove > > all of the reference to them, like menu items (pretty easy to find), > > keyboard shortcuts and context menu items. > > > > ☆PhistucK > > > > > > > > On Wed, Jul 15, 2009 at 10:50, Kruncher wrote: > > > > > Hi, > > > > > I would like to create a custom browser application based on the > > > Chromium source. I have downloaded and compiled the source (from the > > > "Chrome.sln" solution. > > > > > What I want to do is: > > > - Create a new executable project. > > > - Create a custom view that is similar to the "Incognito" view. I > > > would like the browser to start in this view when opened. > > > > > However, I do not want/need to include the regular or "Incognito" > > > views, and I want to strip out all of the JavaScript/DOM debugging > > > parts. > > > > > I would really appreciate it if someone could give me some guidelines. > > > I have had a read through some of the sources, and I have a rough idea > > > as to how the projects are structured. > > > > > Many thanks, > > > Lea Hayes > > > --~--~-~--~~~---~--~~ 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: Creating a Custom View
Thanks for your fast reply! When you made your changes, did you start with a new project, or did you edit the Chromium browser itself? I was considering just modifying the browser. My concern was that if I wanted to update the Chromium trunk, I would need to redo my various changes to the system. Thanks again, On 15 July, 09:31, PhistucK wrote: > It is actually pretty easy to do that, I guess.I changed chromium to support > another button in the toolbar with a keyboard shortcut and removed the > "About Chromium" menu really easily - and my knowledge in C++ is nearly > nonexistent (I only know the syntax since it is similar to JavaScript). > > You should look at the code that uses the regular window and the code that > uses the incognito window (use the theme GRD files for hints to what to > search for, like the Incognito logo and its ID) and compare the two, move > the things that fit you from incognito back into the regular window. > The debugger and everything, you can leave them in the code, simply remove > all of the reference to them, like menu items (pretty easy to find), > keyboard shortcuts and context menu items. > > ☆PhistucK > > > > On Wed, Jul 15, 2009 at 10:50, Kruncher wrote: > > > Hi, > > > I would like to create a custom browser application based on the > > Chromium source. I have downloaded and compiled the source (from the > > "Chrome.sln" solution. > > > What I want to do is: > > - Create a new executable project. > > - Create a custom view that is similar to the "Incognito" view. I > > would like the browser to start in this view when opened. > > > However, I do not want/need to include the regular or "Incognito" > > views, and I want to strip out all of the JavaScript/DOM debugging > > parts. > > > I would really appreciate it if someone could give me some guidelines. > > I have had a read through some of the sources, and I have a rough idea > > as to how the projects are structured. > > > Many thanks, > > Lea Hayes --~--~-~--~~~---~--~~ 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: Creating a Custom View
It is actually pretty easy to do that, I guess.I changed chromium to support another button in the toolbar with a keyboard shortcut and removed the "About Chromium" menu really easily - and my knowledge in C++ is nearly nonexistent (I only know the syntax since it is similar to JavaScript). You should look at the code that uses the regular window and the code that uses the incognito window (use the theme GRD files for hints to what to search for, like the Incognito logo and its ID) and compare the two, move the things that fit you from incognito back into the regular window. The debugger and everything, you can leave them in the code, simply remove all of the reference to them, like menu items (pretty easy to find), keyboard shortcuts and context menu items. ☆PhistucK On Wed, Jul 15, 2009 at 10:50, Kruncher wrote: > > Hi, > > I would like to create a custom browser application based on the > Chromium source. I have downloaded and compiled the source (from the > "Chrome.sln" solution. > > What I want to do is: > - Create a new executable project. > - Create a custom view that is similar to the "Incognito" view. I > would like the browser to start in this view when opened. > > However, I do not want/need to include the regular or "Incognito" > views, and I want to strip out all of the JavaScript/DOM debugging > parts. > > I would really appreciate it if someone could give me some guidelines. > I have had a read through some of the sources, and I have a rough idea > as to how the projects are structured. > > Many thanks, > Lea Hayes > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Creating a Custom View
Hi, I would like to create a custom browser application based on the Chromium source. I have downloaded and compiled the source (from the "Chrome.sln" solution. What I want to do is: - Create a new executable project. - Create a custom view that is similar to the "Incognito" view. I would like the browser to start in this view when opened. However, I do not want/need to include the regular or "Incognito" views, and I want to strip out all of the JavaScript/DOM debugging parts. I would really appreciate it if someone could give me some guidelines. I have had a read through some of the sources, and I have a rough idea as to how the projects are structured. Many thanks, Lea Hayes --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
