[chromium-dev] Re: Binary File Access
Hi,I don't know what the current status on the new xhr API implementation is, but from what you describe it sounds like some V8 bindings may be missing. Also a quick glance at the layout test list shows there are some related broken tests. I'd recommend filing bugs about this at: http://code.google.com/p/chromium/issues/entry You might also want to test on very latest builds to see what repros: http://build.chromium.org/buildbot/continuous/LATEST/chrome-win32.zip On Fri, Mar 20, 2009 at 3:03 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > Ok, I know it's Friday :D ... but, nothing here? > > > On Thu, Mar 19, 2009 at 10:53 PM, Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > >> >> Hi there, I hope it is the right group (and sorry if it is not). >> I've tested a while the new multiple file upload feature and it seems >> to work almost as Safari except for: >> 1 - files has not indexes to get properties, files.item(N) is >> required instead of files[N] (not a problem, really ...) >> 2 - xhr events are fired only via addEventListner, xhr.onload does >> not work (as point 1, not a problem, just different from WebKit) >> 3 - fileSize is ALWAYS 0 ... this is a problem! >> 4 - loaded and position behave as FireFox 3, always 2 ... it does not >> *apparently* make sense >> 5 - there is no sendAsBinary and/or getAsBinary, but the binary >> content is not exposed when a file is sent via xhr.send(files.item >> (0)) // [object File] ... not that useful upload! >> >> Windows XP Fully Updated and Chrome 2.0.169.1 >> >> Any chance I will be able to send a file to the server? Thank You. >> >> >> > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Need advice on where localStorage should live
*If you don't care where various bits of the localStorage implementation live and you aren't scared about letting stuff out of the sandbox, you can stop reading now.* * * Background: For those who don't know the spec by heart: SessionStorage can be thought of as 'tab local' storage space for each origin. LocalStorage is shared across all browser windows of the same origin and is persistent. All data is stored in key/value pairs where both the key and value are strings. It's possible to subscribe to DOM storage events. Events and ease of use are why a developer might use localStorage even though the database interface exists. The exact spec is here: http://dev.w3.org/html5/webstorage/ *Where should the localStorage implementation live? * I'm planning on implementing localStorage very soon within Chromium. Unfortunately, how to do this is not very clearcut. Here are all the possibilities I know of so far: (Note that I'm intentionally ignoring the backing file format for now...as that debate will partially depend on how it's implemented.) 1) The most obvious solution is to have have the browser process keep track of the key/values for each origin and write it to disk. The problem with this approach is that we're allowing user supplied data to exist in memory (possibly the stack at times, though we could probably avoid this if we tried) outside of a sandbox. Ian Fette (and I'm sure others) have pretty big reservations for this reason. That said, this is definitely the simplest and cleanest solution, so if we can figure out something that we're confident with security wise, this is how I'd like to do it. 2) What follows from #1 is simply pulling all the localStorage code into its own (sandboxed) process. The problem is that, unless a lot of the internet starts using localStorage, it seems disproportionately heavy weight. Starting it on demand and killing it off if localStorage hasn't been used for a while would mitigate. 3) A completely different solution is to use shared memory + the code recently written to pass file handles between processes. The shared memory would be used to coordinate between processes and to store key/val data. One render process for each origin will take responsibility for syncing data to disk. Event notifications can occur either via IPC (though sharing key/val data can NOT for latency/responsiveness reasons) or shared memory--whichever is easier. Obviously the chief problem with this is memory usage. I'm sure it'll also be more complex and have a greater bug/exploit cross section. 4) A variation of #3 would be to keep all key/val data in the file and only use shared memory for locking (if necessary). I'm not going to discuss the implementation details because I don't want us to get hung up on them, but the general idea would be for each process to have an open file handle for their origin(s) and somehow (shared memory, flock, etc) coordinate with the other processes. This will almost certainly be slower than memory (if nothing else, due to system calls) but it'll use less memory and possibly be easier to make secure. 5) One last option is to layer the whole thing on top of the HTML 5 database layer. Unfortunately, there's no efficient way for this layer to support events. Even hooking directly into sqlite won't work since its triggers layer apparently only notifies you (i.e. works) if the insert/delete/update happens in your own process. Of course sqlite can be the backing for any other option, but please, let's hold off on that discussion for now. *So here are my questions:* How paranoid should we be about passing a user created string to the browsing process and having it send the data on to the renderer and some backend like sqlite? Do we trust sqlite enough to use it outside of a sandbox? (Hopefully, because we're already doing this, right? If not are there other mechanisms for storing the data on disk that we do trust?) Would we feel more comfortable with #1 if the renderer processes somehow mangled the keys and values before sending them out? For example, they could base64 encode them or even do something non-deterministic so that attackers have no guarantee about what the memory would look like that's passing through the browser process? And, most importantly, which option seems best to you? (Or is there an option 6 that I missed?) I'd rank them 1, 2, 4, 3 personally. --~--~-~--~~~---~--~~ 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: Setting Default Search Engine
Thanks. I wasn't even aware there was an Open Search specification. I must say though, it's pretty impressive that Chrome automatically picks up search engines. If it were any other browser I would have recommended a front-end notification of this action, but for Chrome, it's great just the way it is because it could get annoying seeing a sleeve pop up every site you go to telling you about a search engine you don't even care about. it's best to do it in the background, and if the user is interested in changing the engine, he'll have the options in the list. On Mar 20, 6:36 pm, Pam Greene wrote: > Yes, Chromium supports the OpenSearch specification. As you browse pages, if > they offer a search engine (a tag), we'll pick it up and > automatically add it to the list of engines available in the browser. For > instance, visithttp://www.slashdot.org/and their engine will be detected > and automatically added. For that matter, if you visited Mycroft as Adam > mentioned, you now have Mycroft's own search available. > > We also support the JavaScript window.external.AddSearchProvider() call that > Mycroft and other sites use, to let you add an engine by clicking on a link > or button. > > The part we don't (yet) do is let you set the engine as your default at the > same time as you add it. To see all the engines Chromium has encountered > and choose one for your default, either right-click on the Omnibox and pick > "Edit search engines..." or pick Options from the wrench menu, go to Basics, > and then either pick one of the suggested defaults or click "Manage" for the > full list. (Engines that come with Chrome, and any you add by clicking, are > part of the suggested defaults list. Engines that were added by > automatically detecting them are only on the full list, until you promote > them.) > > I should write a blog post about this sometime. > > - Pam > > > > On Fri, Mar 20, 2009 at 2:41 PM, Adam Barth wrote: > > > Yeah, this great works in Chrome. Head over to > >http://mycroft.mozdev.org/search-engines.htmland try adding any of > > the OpenSearch search engines (with the A9 logos). > > > Adam > > > On Fri, Mar 20, 2009 at 2:19 PM, Meok wrote: > > > > I'm not talking about tricking someone into setting a search engine. > > > i'm talking about how Firefox has a page that you can click on a list > > > of search engines to install them into the browser. IE8 does the same > > > thing. The user has to confirm that they really want the search engine > > > installed or set as default. I guess this would fall under the > > > "extensions framework" but you can do it manually in Chrome (which is > > > great) but I just wondered if there was an automated way to do it as > > > well, like Firefox. I hope that's clear. > > > > On Mar 20, 4:23 pm, Adam Langley wrote: > > >> On Fri, Mar 20, 2009 at 7:57 AM, Meok wrote: > > >> > My question is, whether or not there is code which will trigger > > >> > Chromium to change the default search engine? In other words, can I > > >> > make an html link that when clicked on, will set the default search > > >> > engine in Chromium to that of my website? > > > >> If you find such a security bug, please tell us so that we can fix 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: Setting Default Search Engine
Yes, Chromium supports the OpenSearch specification. As you browse pages, if they offer a search engine (a tag), we'll pick it up and automatically add it to the list of engines available in the browser. For instance, visit http://www.slashdot.org/ and their engine will be detected and automatically added. For that matter, if you visited Mycroft as Adam mentioned, you now have Mycroft's own search available. We also support the JavaScript window.external.AddSearchProvider() call that Mycroft and other sites use, to let you add an engine by clicking on a link or button. The part we don't (yet) do is let you set the engine as your default at the same time as you add it. To see all the engines Chromium has encountered and choose one for your default, either right-click on the Omnibox and pick "Edit search engines..." or pick Options from the wrench menu, go to Basics, and then either pick one of the suggested defaults or click "Manage" for the full list. (Engines that come with Chrome, and any you add by clicking, are part of the suggested defaults list. Engines that were added by automatically detecting them are only on the full list, until you promote them.) I should write a blog post about this sometime. - Pam On Fri, Mar 20, 2009 at 2:41 PM, Adam Barth wrote: > > Yeah, this great works in Chrome. Head over to > http://mycroft.mozdev.org/search-engines.html and try adding any of > the OpenSearch search engines (with the A9 logos). > > Adam > > > On Fri, Mar 20, 2009 at 2:19 PM, Meok wrote: > > > > I'm not talking about tricking someone into setting a search engine. > > i'm talking about how Firefox has a page that you can click on a list > > of search engines to install them into the browser. IE8 does the same > > thing. The user has to confirm that they really want the search engine > > installed or set as default. I guess this would fall under the > > "extensions framework" but you can do it manually in Chrome (which is > > great) but I just wondered if there was an automated way to do it as > > well, like Firefox. I hope that's clear. > > > > On Mar 20, 4:23 pm, Adam Langley wrote: > >> On Fri, Mar 20, 2009 at 7:57 AM, Meok wrote: > >> > My question is, whether or not there is code which will trigger > >> > Chromium to change the default search engine? In other words, can I > >> > make an html link that when clicked on, will set the default search > >> > engine in Chromium to that of my website? > >> > >> If you find such a security bug, please tell us so that we can fix 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: Quick translation question: "activatable"
Ah. Thanks. Avi On Fri, Mar 20, 2009 at 5:07 PM, Peter Kasting wrote: > On Fri, Mar 20, 2009 at 2:03 PM, Avi Drissman wrote: > >> The term "activatable", as seen in RenderWidgetHostViewWin, etc, is not >> clearly defined. > > > Windows has two concepts relating to focus: focus and activation. > > A focused window is the window that would receive input events if its > highest ancestor window were foreground. An activated window is the focused > window in the foreground root-level window. Activating a window makes it > focused and makes its root foreground. > > The autocomplete popup window cannot be activated, meaning it can never > receive input events. > > 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: Binary File Access
Ok, I know it's Friday :D ... but, nothing here? On Thu, Mar 19, 2009 at 10:53 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > > Hi there, I hope it is the right group (and sorry if it is not). > I've tested a while the new multiple file upload feature and it seems > to work almost as Safari except for: > 1 - files has not indexes to get properties, files.item(N) is > required instead of files[N] (not a problem, really ...) > 2 - xhr events are fired only via addEventListner, xhr.onload does > not work (as point 1, not a problem, just different from WebKit) > 3 - fileSize is ALWAYS 0 ... this is a problem! > 4 - loaded and position behave as FireFox 3, always 2 ... it does not > *apparently* make sense > 5 - there is no sendAsBinary and/or getAsBinary, but the binary > content is not exposed when a file is sent via xhr.send(files.item > (0)) // [object File] ... not that useful upload! > > Windows XP Fully Updated and Chrome 2.0.169.1 > > Any chance I will be able to send a file to the server? Thank You. > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Linux ui_tests
I just checked in a change which makes first UI test run on Linux. The lucky winner is ImagesTest.AnimatedGIFs. Enjoy! Paweł --~--~-~--~~~---~--~~ 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: Setting Default Search Engine
Yeah, this great works in Chrome. Head over to http://mycroft.mozdev.org/search-engines.html and try adding any of the OpenSearch search engines (with the A9 logos). Adam On Fri, Mar 20, 2009 at 2:19 PM, Meok wrote: > > I'm not talking about tricking someone into setting a search engine. > i'm talking about how Firefox has a page that you can click on a list > of search engines to install them into the browser. IE8 does the same > thing. The user has to confirm that they really want the search engine > installed or set as default. I guess this would fall under the > "extensions framework" but you can do it manually in Chrome (which is > great) but I just wondered if there was an automated way to do it as > well, like Firefox. I hope that's clear. > > On Mar 20, 4:23 pm, Adam Langley wrote: >> On Fri, Mar 20, 2009 at 7:57 AM, Meok wrote: >> > My question is, whether or not there is code which will trigger >> > Chromium to change the default search engine? In other words, can I >> > make an html link that when clicked on, will set the default search >> > engine in Chromium to that of my website? >> >> If you find such a security bug, please tell us so that we can fix 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: Setting Default Search Engine
I'm not talking about tricking someone into setting a search engine. i'm talking about how Firefox has a page that you can click on a list of search engines to install them into the browser. IE8 does the same thing. The user has to confirm that they really want the search engine installed or set as default. I guess this would fall under the "extensions framework" but you can do it manually in Chrome (which is great) but I just wondered if there was an automated way to do it as well, like Firefox. I hope that's clear. On Mar 20, 4:23 pm, Adam Langley wrote: > On Fri, Mar 20, 2009 at 7:57 AM, Meok wrote: > > My question is, whether or not there is code which will trigger > > Chromium to change the default search engine? In other words, can I > > make an html link that when clicked on, will set the default search > > engine in Chromium to that of my website? > > If you find such a security bug, please tell us so that we can fix 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: Same Origin Policy implementation
The same-origin policy checks are implemented in the WebKit component. You might be interested in the WebCore::SecurityOrigin class that is in charge of such things. Adam On Fri, Mar 20, 2009 at 10:03 AM, Sasidhar Kasturi wrote: > > Hello, > I am planning to change and test various details of the same > origin policy for chrome as part of my project. I had setup the > development environment and built chrome. As described in the Browser > hand book (http://code.google.com/p/browsersec/wiki/Main) there are > individual policies for > 1. DOM access > 2. Ajax > 3. cookies. > > I would like to know where and how is the policy for each of them > implemented in the code tree of chrome. > > Regards, > - Sasidhar. > > > > --~--~-~--~~~---~--~~ 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: Quick translation question: "activatable"
On Fri, Mar 20, 2009 at 2:03 PM, Avi Drissman wrote: > The term "activatable", as seen in RenderWidgetHostViewWin, etc, is not > clearly defined. Windows has two concepts relating to focus: focus and activation. A focused window is the window that would receive input events if its highest ancestor window were foreground. An activated window is the focused window in the foreground root-level window. Activating a window makes it focused and makes its root foreground. The autocomplete popup window cannot be activated, meaning it can never receive input events. 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] Quick translation question: "activatable"
The term "activatable", as seen in RenderWidgetHostViewWin, etc, is not clearly defined. The only explanation I've found is: "Autocomplete popup windows for example cannot be activated." Can someone provide a meaning? Does that mean that it can never become the focus for keystrokes? I get a vague idea from googling SW_SHOWNA but it's not quite clear. 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: Setting Default Search Engine
On Fri, Mar 20, 2009 at 7:57 AM, Meok wrote: > My question is, whether or not there is code which will trigger > Chromium to change the default search engine? In other words, can I > make an html link that when clicked on, will set the default search > engine in Chromium to that of my website? If you find such a security bug, please tell us so that we can fix 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] Same Origin Policy implementation
Hello, I am planning to change and test various details of the same origin policy for chrome as part of my project. I had setup the development environment and built chrome. As described in the Browser hand book (http://code.google.com/p/browsersec/wiki/Main) there are individual policies for 1. DOM access 2. Ajax 3. cookies. I would like to know where and how is the policy for each of them implemented in the code tree of chrome. Regards, - Sasidhar. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Setting Default Search Engine
I hope this is the right place to ask this question. Chrome is the only browser I've found that lets me specify the URL of a new default search engine. This allows me to set my default search engine as that of ANY site with a search box and is much appreciated. My question is, whether or not there is code which will trigger Chromium to change the default search engine? In other words, can I make an html link that when clicked on, will set the default search engine in Chromium to that of my website? --~--~-~--~~~---~--~~ 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] toolstrip default CSS
I tried skipping the assert and then it just didn't paint the gradient. But you're right, technically, not a crash. Thanks for the bug reference. I will just move the gradient to a div! - a On Fri, Mar 20, 2009 at 11:00 AM, Matt Perry wrote: > FYI, the gradient "crash" (assert really) is > https://bugs.webkit.org/show_bug.cgi?id=18445 . It's fairly old. It > only happens for gradients on the body element, so a simple workaround > is to put everything in a div and set the gradient there. > > On Thu, Mar 19, 2009 at 10:04 PM, Aaron Boodman wrote: >> >> I have a CL that implements default CSS for toolstrips to make 'em >> pretty (well, relatively pretty). But it doesn't work because the >> gradient crashes in webkit for some reason. >> >> Anyway, this isn't a huge need at this moment, so I'll probably >> abandon the change for now. But if anyone later wants to pick it up, >> here it is: >> >> http://codereview.chromium.org/42435 >> >> - 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: Top level browsing contexts and processes
On Fri, Mar 20, 2009 at 10:23 AM, Jeremy Orlow wrote: > Are there any plans (long term or short) to render stuff like iframes with > a different origin inside a different process? Does the story get more > complicated with plugs and extensions? > > *More background:* > I'm looking at implementing window.sessionStorage. It's spec ( > http://dev.w3.org/html5/webstorage/#the-sessionstorage-attribute) says: > > The sessionStorage attribute represents the set of storage areas specific > to the current top-level browsing context. > > Each top-level browsing context has a unique set of session storage areas, > one for each origin. > > Webkit already has a nice implementation that should actually work pretty > well for chrome, provided that there's never more than one process per > top-level browsing context. > > One area that seems much more murky to me is plugins. I assume that if a > plugin interacts with a page's javascript, it'll be doing it in that page's > render process...is this correct? > yep that's correct. > > Are there any complications extensions might add? > > > Thanks! > J > > > > --~--~-~--~~~---~--~~ 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: Top level browsing contexts and processes
In the long term, we do plan to support out-of-process iframes, but you shouldn't let this constrain our sessionStorage implementation. Adam On Fri, Mar 20, 2009 at 10:23 AM, Jeremy Orlow wrote: > Are there any plans (long term or short) to render stuff like iframes with a > different origin inside a different process? Does the story get more > complicated with plugs and extensions? > > More background: > I'm looking at implementing window.sessionStorage. It's spec > (http://dev.w3.org/html5/webstorage/#the-sessionstorage-attribute) says: > > The sessionStorage attribute represents the set of storage areas specific to > the current top-level browsing context. > > Each top-level browsing context has a unique set of session storage areas, > one for each origin. > > Webkit already has a nice implementation that should actually work pretty > well for chrome, provided that there's never more than one process per > top-level browsing context. > One area that seems much more murky to me is plugins. I assume that if a > plugin interacts with a page's javascript, it'll be doing it in that page's > render process...is this correct? > Are there any complications extensions might add? > > Thanks! > J > > > --~--~-~--~~~---~--~~ 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: [Chrome-team] Need Owners for 9 Layout Test Failures
This time from my chromium account: These are from recent merges. Bugs are being filed on these and owners assigned. Also, we're at 31 tests remaining. -Scott 2009/3/20 Jonathan Conradt : > We are very close to closing out all of the layout test failures. We have > about 20 to finish. > Unfortunately, there are 9 without owners. Please grab one. > > LayoutTests/http/tests/misc/url-in-utf16be.html > LayoutTests/http/tests/misc/url-in-utf16le.html > LayoutTests/css2.1/t0905-c5526-flthw-00-c-g.html > LayoutTests/editing/style/block-styles-007.html > LayoutTests/http/tests/xmlhttprequest/redirect-cross-origin-post.html > LayoutTests/http/tests/xmlhttprequest/simple-cross-origin-progress-events.html > LayoutTests/http/tests/security/cross-frame-access-history-put.html > LayoutTests/fast/canvas/fillrect_gradient.html > > Go to http://go/layout-bugs and put your alias in the Owner Email column and > fix it. :) > Jon > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Top level browsing contexts and processes
Are there any plans (long term or short) to render stuff like iframes with a different origin inside a different process? Does the story get more complicated with plugs and extensions? *More background:* I'm looking at implementing window.sessionStorage. It's spec ( http://dev.w3.org/html5/webstorage/#the-sessionstorage-attribute) says: The sessionStorage attribute represents the set of storage areas specific to the current top-level browsing context. Each top-level browsing context has a unique set of session storage areas, one for each origin. Webkit already has a nice implementation that should actually work pretty well for chrome, provided that there's never more than one process per top-level browsing context. One area that seems much more murky to me is plugins. I assume that if a plugin interacts with a page's javascript, it'll be doing it in that page's render process...is this correct? Are there any complications extensions might add? Thanks! J --~--~-~--~~~---~--~~ 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: ResourceMessageFilter::OnGet(Root)WindowRect and NULL windows
On Fri, Mar 20, 2009 at 8:11 AM, Avi Drissman wrote: > http://codereview.chromium.org/47002 > http://crbug.com/9060 There's several parts here: * Why is the renderer asking questions about a NULL NativeViewId? * Why does that result in a NULL pointer in the browser? I don't know the answer to the first. It's probably some assumption in WebKit which assumes that it has a valid window at all times and we break that with multiprocess. However, it seems to be harmless. As for the second: we currently take pointers, raw from the renderer. This is just a hack. At some point, we need to make NativeViewIds be something else and have a proper translation layer. But we don't yet. 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: ResourceMessageFilter::OnGet(Root)WindowRect and NULL windows
http://codereview.chromium.org/47002 http://crbug.com/9060 Avi On Fri, Mar 20, 2009 at 10:58 AM, Avi Drissman wrote: > I don't disagree with the statement "you shouldn't let the renderer crash > the browser" but I'm trying to understand if a null window ref is an > expected value for those functions to handle. > > If so, the Windows version should explicitly check rather than relying on > the fact that the Win32 APIs happen to handle that case by accident. > > If not, we need to figure out why those null window refs are coming > through. > > Is there anyone who knows what's going on here and can answer this > question? > > Avi > /who just wrote this into code in http://codereview.chromium.org/47002 > > On Thu, Mar 19, 2009 at 1:46 PM, Craig Schlenter < > craig.schlen...@gmail.com> wrote: > >> Hi Avi >> >> When I did the original change, that function wasn't being called with >> a null window. >> Clicking on a link in gmail opened the link in a new window as I >> recall. At some later >> point that changed possibly when some of the tab_contents stuff was hooked >> up. I >> think it's good practice to check for null since you don't want the >> renderer to be able >> to crash the browser but I do tend to think that it shouldn't be >> happening to begin with >> but I'm largely clueless about the code involved :( >> >> Perhaps someone with a windows build can put a breakpoint in >> OnGetRootWindowRect please and see if clicking on a link in an >> email in gmail passes a HWND of null at all? >> >> Thank you, >> >> --Craig >> >> On Thu, Mar 19, 2009 at 7:33 PM, Avi Drissman wrote: >> > We've been seeing calls to ResourceMessageFilter::OnGet(Root)WindowRect >> for >> > NULL windows. agl put in a fix for GTK with >> > http://codereview.chromium.org/42356 and I'm seeing the same problem on >> the >> > Mac. >> > >> > 1. Why isn't Windows seeing this? What happens when you pass a null HWND >> > into ::GetAncestor and ::GetWindowRect? >> > 2. Is this expected, or is this indicative of a bug? >> > >> > 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: ResourceMessageFilter::OnGet(Root)WindowRect and NULL windows
I don't disagree with the statement "you shouldn't let the renderer crash the browser" but I'm trying to understand if a null window ref is an expected value for those functions to handle. If so, the Windows version should explicitly check rather than relying on the fact that the Win32 APIs happen to handle that case by accident. If not, we need to figure out why those null window refs are coming through. Is there anyone who knows what's going on here and can answer this question? Avi /who just wrote this into code in http://codereview.chromium.org/47002 On Thu, Mar 19, 2009 at 1:46 PM, Craig Schlenter wrote: > Hi Avi > > When I did the original change, that function wasn't being called with > a null window. > Clicking on a link in gmail opened the link in a new window as I > recall. At some later > point that changed possibly when some of the tab_contents stuff was hooked > up. I > think it's good practice to check for null since you don't want the > renderer to be able > to crash the browser but I do tend to think that it shouldn't be > happening to begin with > but I'm largely clueless about the code involved :( > > Perhaps someone with a windows build can put a breakpoint in > OnGetRootWindowRect please and see if clicking on a link in an > email in gmail passes a HWND of null at all? > > Thank you, > > --Craig > > On Thu, Mar 19, 2009 at 7:33 PM, Avi Drissman wrote: > > We've been seeing calls to ResourceMessageFilter::OnGet(Root)WindowRect > for > > NULL windows. agl put in a fix for GTK with > > http://codereview.chromium.org/42356 and I'm seeing the same problem on > the > > Mac. > > > > 1. Why isn't Windows seeing this? What happens when you pass a null HWND > > into ::GetAncestor and ::GetWindowRect? > > 2. Is this expected, or is this indicative of a bug? > > > > 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: Omnibox q around Mac+Chromium best-practices.
The rest of the UI so far is trending towards the reverse, thin C++ and thick objc controllers (usually subclasses of NSViewController). If you're debugging at the UI layer, there's going to be plenty of cocoa and objective-c, I don't think you can avoid it. Even a C++ class is going to have obj-c in it if it talks to the UI at all. I'm fine with a mix, personally. Draw the line where you think it's most appropriate. On Thu, Mar 19, 2009 at 7:08 PM, Brett Wilson wrote: > > I would do the thin Objective C mode, partially since all Chrome > developers know C++. I could debug that code or make changes to it if > I was doing something that affected it, but I would have a much harder > time with Objective-C. > > Brett > > On Thu, Mar 19, 2009 at 4:00 PM, Scott Hess wrote: >> >> I'm refactoring my Omnibox code towards something I'm willing to put >> up for review, and am realizing that I need to find a way to rule on >> whether I should have thick Objective-C helpers or thin ones. Say for >> instance that I have an NSTableView, I'll need a data source for that, >> which needs to be an Objective-C object. At the thin extreme, I can >> put the minimum amount of code in that object to fulfill the data >> source protocol, plus anything I need for handling delegation or >> target/action type things, which leaves setup and wiring in the C++ >> code. At the thick extreme I would push most of the Objective-C code >> into the Objective-C object, and have the C++ code call into that. Or >> there's something in the middle. >> >> WDYT? >> >> Right now it's somewhere in the middle. I don't create Objective-C >> methods solely to be called from C++, nor C++ methods solely to be >> called from Objective-C, except for cases where either would need to >> poke through the encapsulation boundary. >> >> Thanks, >> scott >> >> > >> > > > > -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Binary File Access
Hi there, I hope it is the right group (and sorry if it is not). I've tested a while the new multiple file upload feature and it seems to work almost as Safari except for: 1 - files has not indexes to get properties, files.item(N) is required instead of files[N] (not a problem, really ...) 2 - xhr events are fired only via addEventListner, xhr.onload does not work (as point 1, not a problem, just different from WebKit) 3 - fileSize is ALWAYS 0 ... this is a problem! 4 - loaded and position behave as FireFox 3, always 2 ... it does not *apparently* make sense 5 - there is no sendAsBinary and/or getAsBinary, but the binary content is not exposed when a file is sent via xhr.send(files.item (0)) // [object File] ... not that useful upload! Windows XP Fully Updated and Chrome 2.0.169.1 Any chance I will be able to send a file to the server? Thank You. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
