[chromium-dev] Re: RE : chrome's testing
It does not depend on scope. By default, every change that is uploaded by a committer for code review gets built on all three platforms by Google's try servers. --Amanda 2009/6/7 PhistucK phist...@gmail.com I forgot about the cross platform compiling stuff. I do not think every change is going through the try bot first, but only stuff that has greater scopes. About the testing thing, it says there Here is a list of some of the tests currently used by Chromium:, so those are only some of them. ☆PhistucK 2009/6/8 sitan2...@sina.com A Try Bot is a machine that gets sent code patches and instantly (or not instantly) builds chrome with these changes with the latest source. That is the place to see if the things you want to commit are fine, I guess mostly big, could-be-breaking changes are getting sent there. Of course, only Chrome developers (Googlers) and contributors that can commit, can use the try bots. The TryBot is cool. Does that mean Googlers first submit theirs codes to trybots to test if all the codes are OK, if OK, then they submit their codes to buildbots for the final automated building and testing ? 2009/6/7 nakro yoav.zilberb...@gmail.com Regarding 1 : at least for VS2008 the tests seemed to have been moved to the chrome folder (i know that ui_tests.vcproj and unit_tests.vcproj have been moved there) well, nakro, that's the problem. I use vs2005, and I found 42 projects under Test. But at http://dev.chromium.org/developers/testing;, there're only 22 projects listed. What about the other 20 projects. I want to learn something from chromium's testing, for I think it really organized well for a big project. --~--~-~--~~~---~--~~ 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: What is the best way to get document location from an NPAPI plugin?
On Sun, Jun 7, 2009 at 10:57 PM, vijay tec...@gmail.com wrote: Preferably a browser-independent way would be great. A quick Google search for NPAPI docs turned up https://developer.mozilla.org/en/Gecko_Plugin_API_Reference . I suspect starting there would be good. 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: Is there any way to know if a web page is fully loaded from the Browser object
2009/6/7 PhistucK phist...@gmail.com As a hacky workaround, you can create an embedded userscript with an onload event window.print() and trigger it whenever there is a --print-page switch.:P I'm not sure if onload is guaranteed to not fire until after all pieces of content have fully loaded. I always forget which of the various load events means what. 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: What is the best way to get document location from an NPAPI plugin?
This turns out to be very trick to do securely. I recommend studying how Flash does this and doing *precisely* the same thing. Adam On Sun, Jun 7, 2009 at 10:57 PM, vijaytec...@gmail.com wrote: Preferably a browser-independent way would be great. Thanks in advance, Vijay --~--~-~--~~~---~--~~ 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: Is there any way to know if a web page is fully loaded from the Browser object
I think the question of when a page is fully loaded is a bit hard to get perfect... as lots of pages do stuff after they've loaded that won't really impact the presentation... but there is no way to know that the JS programs won't make further changes :-/. That said, Dave Moore put in some code to try to histogram some interesting durations. Take a look at: chrome/trunk/src/chrome/renderer/render_view.cc: around line 2830. Search for the text Renderer2.RequestToFinish That seems to include a very educated guess at what finished is, as it times the interval from the request until he thought the page load was very complete. You might look around at related code and see if you can identify an interesting point/hook for your purposes. Hope that helps, Jim On Sun, Jun 7, 2009 at 10:45 PM, Mohamed Mansour m0.interact...@gmail.comwrote: Hi chromium, I have been working on some feature (automatic printing) where it requires the page to be fully loaded before I bring up the printer dialog and print. The printer dialog (native to windows) blocks the UI so the page being loaded is still white, hence it prints a white page. After the I press 'ok' on print dialog, the white page fully renders correctly. My question is this, how can I ensure all the page elements are finished loading? There seems to be no asynchronous event I could use to wait till a page has been fully loaded. Any ideas? -- Mohamed Mansour --~--~-~--~~~---~--~~ 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: Is there any way to know if a web page is fully loaded from the Browser object
Yea, that was the first thing that came into my mind. I don't know if I am looking at the right place but from what I have read before, I would need to use the NotificationRegistrar and register myself to some NotificationType. There isn't any notification type that says page done or anything similar. The closest I seen was DOM_OPERATION_RESPONSE or NAV_ENTRY_COMMITTED unless I was looking in the wrong place. Its still not great and the page is still white, unless I press the big ok button on the print dialog then everything renders fine. -- Mohamed Mansour On Mon, Jun 8, 2009 at 1:51 AM, Peter Kasting pkast...@google.com wrote: On Sun, Jun 7, 2009 at 10:45 PM, Mohamed Mansour m0.interact...@gmail.com wrote: My question is this, how can I ensure all the page elements are finished loading? There seems to be no asynchronous event I could use to wait till a page has been fully loaded. Any ideas? Have you tried tracing backwards from whatever stops the throbber spinning? 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: Is there any way to know if a web page is fully loaded from the Browser object
Can you check for any renderer HTTP requests? sort of once it is done, you can fire the event.(Unless it is a never ending AJAX generated page, but the problem persists in any mode with no timeout.) Sorry for blabbing. ☆PhistucK On Mon, Jun 8, 2009 at 09:48, Mohamed Mansour m0.interact...@gmail.comwrote: Yea, that was the first thing that came into my mind. I don't know if I am looking at the right place but from what I have read before, I would need to use the NotificationRegistrar and register myself to some NotificationType. There isn't any notification type that says page done or anything similar. The closest I seen was DOM_OPERATION_RESPONSE or NAV_ENTRY_COMMITTED unless I was looking in the wrong place. Its still not great and the page is still white, unless I press the big ok button on the print dialog then everything renders fine. -- Mohamed Mansour On Mon, Jun 8, 2009 at 1:51 AM, Peter Kasting pkast...@google.com wrote: On Sun, Jun 7, 2009 at 10:45 PM, Mohamed Mansour m0.interact...@gmail.com wrote: My question is this, how can I ensure all the page elements are finished loading? There seems to be no asynchronous event I could use to wait till a page has been fully loaded. Any ideas? Have you tried tracing backwards from whatever stops the throbber spinning? 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: What is the best way to get document location from an NPAPI plugin?
On Sun, Jun 7, 2009 at 10:57 PM, vijaytec...@gmail.com wrote: Preferably a browser-independent way would be great. Thanks in advance, Vijay I believe the best way to do that is to use NPRuntime. Essentially, you programatically query window.location.href using a series of NPN_GetProperty. See for example http://code.google.com/p/omaha/source/browse/trunk/plugins/npOneClick.cc , in the NPOneClickClass::GetUrl function. Antoine --~--~-~--~~~---~--~~ 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: What is the best way to get document location from an NPAPI plugin?
Yeah. Here is what worked for us in the past: we issue a NPN_GetURL with javascript:document.location and the browser simply delivered the location via the standard NPP_NewStream, NPP_Write, etc. This works perfectly with mozilla/firefox. It also used to work the same exact way in Chrome 1.x so our code worked without any problems. However, with Chrome 2.0 (and the webkit underneath it), there were some changes and the javascript results are not being delivered via streams any more. Chrome/webkit is simply executing the javascript and ignoring the results. I can't say I agree with the rationale behind the change but it seems to have killed about the simplest way to get the document location :) On Jun 7, 11:29 pm, Adam Barth aba...@chromium.org wrote: This turns out to be very trick to do securely. I recommend studying how Flash does this and doing *precisely* the same thing. Adam On Sun, Jun 7, 2009 at 10:57 PM, vijaytec...@gmail.com wrote: Preferably a browser-independent way would be great. Thanks in advance, Vijay --~--~-~--~~~---~--~~ 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 crashes - please help
Hi, Chrome just fails in Debug mode... I have tried with and without commandline switches. I am getting following error. [:FATAL:render_widget_host_view_win.cc(557)]Check failed: render_widget_host_-process()-channel() and Whoa! Chromium has crashed. Restart now? What could be the problem? I am not able to proceed with my development. Please help me to resolve this issue. thanks and regards On Jun 5, 7:37 pm, Marc-Antoine Ruel mar...@chromium.org wrote: On Fri, Jun 5, 2009 at 6:10 AM, mailandr...@gmail.com veena...@gmail.comwrote: Hi, I am getting following error when i run the chrome.exe in --single- process switch mode. [5272:5864:264167375:FATAL:render_widget_host_view_win.cc(557)]Check failed: render_widget_host_-process()-channel() after pressing ok i get the message as, Whoa! Chromium has crashed. Restart now? could anyone tell me what situation this error occurs and what could be the mistake the developer would have done? I am badly stuck.. please request to help. thanks and regards --single-process is not maintained and its tests have been downgraded to the For Your Information waterfall athttp://build.chromium.org/buildbot/waterfall.fyi/waterfall We'd probably accept patches to simply remove it or to fix it but I guess removing it will reduce confusion. M-A- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ 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: What is the best way to get document location from an NPAPI plugin?
Thanks Antoine! That worked perfectly for my needs! On Jun 8, 1:28 am, Antoine Labour pi...@google.com wrote: On Sun, Jun 7, 2009 at 10:57 PM, vijaytec...@gmail.com wrote: Preferably a browser-independent way would be great. Thanks in advance, Vijay I believe the best way to do that is to use NPRuntime. Essentially, you programatically query window.location.href using a series of NPN_GetProperty. See for examplehttp://code.google.com/p/omaha/source/browse/trunk/plugins/npOneClick.cc , in the NPOneClickClass::GetUrl function. Antoine --~--~-~--~~~---~--~~ 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: Build errors with VS2008SP1
Mohammed, i am not sure i get your reply or the point of posting it however, i thank the rest of you for being honest about it right now 2008 builds just fine so i can get back to fixing the ui tests for hebrew enabled machine (that last prob was not with _TR1, mohammed, btw) --~--~-~--~~~---~--~~ 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 crashes - please help
On Mon, Jun 8, 2009 at 3:22 AM, mailandr...@gmail.comveena...@gmail.com wrote: Chrome just fails in Debug mode... I have tried with and without commandline switches. I am getting following error. [:FATAL:render_widget_host_view_win.cc(557)]Check failed: render_widget_host_-process()-channel() and Whoa! Chromium has crashed. Restart now? What could be the problem? I am not able to proceed with my development. Please help me to resolve this issue. Do the base and net unit tests pass? Worst case, you could switch to developing in Linux until this goes away, whatever it is. - Dan --~--~-~--~~~---~--~~ 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: Question about BrowserRenderProcessHost::OnPageContents() method
FYI: I just recently added WebFrame::GetFullPageHtml() for print selection support. This could come in handy for debugging. But Brett is right you need to be in the renderer process for that. The alternate is simply to select everything on the page and do a copy. You can do that from the browser process. Sverrir On Sun, Jun 7, 2009 at 2:38 AM, Brett Wilson bre...@chromium.org wrote: On Sat, Jun 6, 2009 at 11:13 PM, meryl silverburgh.me...@gmail.com wrote: Hi, I add debug print status in BrowserRenderProcessHost::OnPageContents () to print out the value of 'contents' void BrowserRenderProcessHost::OnPageContents(const GURL url, int32 page_id, const std::wstring contents); // original code // I add this: cout BrowserRenderProcessHost::OnPageContents endl; cout endl; cout contents; cout endl; } My question is why I only see the 'Text' of the page? I tried loading www.google.ca, but I only see these values: I'm assuming your question is why it doesn't also contain the HTML... This function is called by the renderer with the text of the page so we can index it for history search. As a result, it contains only the text, since we don't want to index the HTML. If you have code that needs to get the full HTML of the page, you need to be in the renderer process and walk the DOM yourself. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is there any way to know if a web page is fully loaded from the Browser object
Hi Mohamed,This overlaps with the work I've been doing so please sync with me before starting any major work. What I've found out so far is that if you have an create a page (using WebView::Create) and have it load a page using html that fully describes the page. For my tests I've been using WebFrame::GetFullPageHtml(). I know when WebKit has constructed the page using the WebViewDelegate::DidStopLoading() callback. I have not investigated how to detect this when additional resources are loaded. Some pages for example use alternate images when you switch them into print mode (using CSS). The work I've been doing the past two weeks is to gradually add support for Print Selection and Print Frame and the plan is start making these asynchronous before changing the full page printing. The reason is simply I want to do this in easy steps so they are easy to backtrack and test. Also one of the problems I've been facing with asynchronous printing is that there is no simple way to copy the full page (DOM if you will) in WebKit. The Html approach is good enough for print selection and hopefully print frame but a more in depth approach is required for full page printing. I suspect for this some WebKit changes are required. Sverrir 2009/6/8 PhistucK phist...@gmail.com Can you check for any renderer HTTP requests? sort of once it is done, you can fire the event.(Unless it is a never ending AJAX generated page, but the problem persists in any mode with no timeout.) Sorry for blabbing. ☆PhistucK On Mon, Jun 8, 2009 at 09:48, Mohamed Mansour m0.interact...@gmail.comwrote: Yea, that was the first thing that came into my mind. I don't know if I am looking at the right place but from what I have read before, I would need to use the NotificationRegistrar and register myself to some NotificationType. There isn't any notification type that says page done or anything similar. The closest I seen was DOM_OPERATION_RESPONSE or NAV_ENTRY_COMMITTED unless I was looking in the wrong place. Its still not great and the page is still white, unless I press the big ok button on the print dialog then everything renders fine. -- Mohamed Mansour On Mon, Jun 8, 2009 at 1:51 AM, Peter Kasting pkast...@google.comwrote: On Sun, Jun 7, 2009 at 10:45 PM, Mohamed Mansour m0.interact...@gmail.com wrote: My question is this, how can I ensure all the page elements are finished loading? There seems to be no asynchronous event I could use to wait till a page has been fully loaded. Any ideas? Have you tried tracing backwards from whatever stops the throbber spinning? 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: What is the best way to get document location from an NPAPI plugin?
Hmm... I'm not exactly sure how Flash works (are there any pointers
to this or do you figure this just by debugging Flash with Chrome?)
but here's the specific problem I'm running into.
We used to use NPN_GetURL with javascript:document.location as the
URL. In the current implementation, after this script is executed in
WebPluginImpl::ExecuteScript (in src/webkit/glue/webplugin_impl.cc),
its checking the result value:
WebCore::ScriptValue result =
frame()-loader()-executeScript(script_str, popups_allowed);
WebCore::String script_result;
std::wstring wresult;
bool succ = false;
if (result.getString(script_result)) {
succ = true;
wresult = webkit_glue::StringToStdWString(script_result);
}
For the above javascript I'm using, the result is false and I'm not
sure why. Because of that, eventually in the
PluginInstance::SendJavaScriptStream, no stream is being created at
all. As I mentioned before this used to work with Chrome 1.x. I'm not
sure why the javascript document.location does not correctly result in
a string. I probably need to dig in more. Does this exact sequence
work correctly for you?
Thanks for all your time btw!
Vijay
On Jun 8, 11:15 am, John Abd-El-Malek j...@chromium.org wrote:
Are you sure this is broken? Flash uses this so if it was broken, we would
have seen lots of sites fail.
On a debug build, I can see this working fine using about:ipc.
NPN_GetProperty is called on location
and the returned object is NPN_Invoke'd to call toString
On Mon, Jun 8, 2009 at 1:38 AM, vijay tec...@gmail.com wrote:
Yeah. Here is what worked for us in the past: we issue a NPN_GetURL
with javascript:document.location and the browser simply delivered
the location via the standard NPP_NewStream, NPP_Write, etc. This
works perfectly with mozilla/firefox. It also used to work the same
exact way in Chrome 1.x so our code worked without any problems.
However, with Chrome 2.0 (and the webkit underneath it), there were
some changes and the javascript results are not being delivered via
streams any more. Chrome/webkit is simply executing the javascript and
ignoring the results. I can't say I agree with the rationale behind
the change but it seems to have killed about the simplest way to get
the document location :)
On Jun 7, 11:29 pm, Adam Barth aba...@chromium.org wrote:
This turns out to be very trick to do securely. I recommend studying
how Flash does this and doing *precisely* the same thing.
Adam
On Sun, Jun 7, 2009 at 10:57 PM, vijaytec...@gmail.com wrote:
Preferably a browser-independent way would be great.
Thanks in advance,
Vijay
--~--~-~--~~~---~--~~
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: What is the best way to get document location from an NPAPI plugin?
Perhaps try javascript:window.location. We have a test for this in
npapi_uitest.cc: GetURL, and it uses window.location successfully.
On Mon, Jun 8, 2009 at 1:29 PM, vijay tec...@gmail.com wrote:
Hmm... I'm not exactly sure how Flash works (are there any pointers
to this or do you figure this just by debugging Flash with Chrome?)
but here's the specific problem I'm running into.
We used to use NPN_GetURL with javascript:document.location as the
URL. In the current implementation, after this script is executed in
WebPluginImpl::ExecuteScript (in src/webkit/glue/webplugin_impl.cc),
its checking the result value:
WebCore::ScriptValue result =
frame()-loader()-executeScript(script_str, popups_allowed);
WebCore::String script_result;
std::wstring wresult;
bool succ = false;
if (result.getString(script_result)) {
succ = true;
wresult = webkit_glue::StringToStdWString(script_result);
}
For the above javascript I'm using, the result is false and I'm not
sure why. Because of that, eventually in the
PluginInstance::SendJavaScriptStream, no stream is being created at
all. As I mentioned before this used to work with Chrome 1.x. I'm not
sure why the javascript document.location does not correctly result in
a string. I probably need to dig in more. Does this exact sequence
work correctly for you?
Thanks for all your time btw!
Vijay
On Jun 8, 11:15 am, John Abd-El-Malek j...@chromium.org wrote:
Are you sure this is broken? Flash uses this so if it was broken, we
would
have seen lots of sites fail.
On a debug build, I can see this working fine using about:ipc.
NPN_GetProperty is called on location
and the returned object is NPN_Invoke'd to call toString
On Mon, Jun 8, 2009 at 1:38 AM, vijay tec...@gmail.com wrote:
Yeah. Here is what worked for us in the past: we issue a NPN_GetURL
with javascript:document.location and the browser simply delivered
the location via the standard NPP_NewStream, NPP_Write, etc. This
works perfectly with mozilla/firefox. It also used to work the same
exact way in Chrome 1.x so our code worked without any problems.
However, with Chrome 2.0 (and the webkit underneath it), there were
some changes and the javascript results are not being delivered via
streams any more. Chrome/webkit is simply executing the javascript and
ignoring the results. I can't say I agree with the rationale behind
the change but it seems to have killed about the simplest way to get
the document location :)
On Jun 7, 11:29 pm, Adam Barth aba...@chromium.org wrote:
This turns out to be very trick to do securely. I recommend studying
how Flash does this and doing *precisely* the same thing.
Adam
On Sun, Jun 7, 2009 at 10:57 PM, vijaytec...@gmail.com wrote:
Preferably a browser-independent way would be great.
Thanks in advance,
Vijay
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] HTTP POST via net package?
How can I upload multipart form data (including a file) via HTTP POST? Is there something already written in the net package (or elsewhere) for this task? If so, can someone please point me to what class to use. Thanks, Daniel --~--~-~--~~~---~--~~ 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: Continuous builds
Awesome. Thanks for making this happen! -Ben On Mon, Jun 8, 2009 at 2:26 PM, Thomas Van Lenten thoma...@chromium.org wrote: The continuous build scripts have been updated to handle all three platforms. If you take the link on the top left of the waterfall pages, you'll go a listing that now includes directories for each platform. Each platform dir then has a LATEST link within it (the LATEST outside of the platform dirs is a Windows one, to make any existing scripts/links using that url still work). I have the scripts currently running to pull the last 30 days worth of builds on Mac and Linux into these directories; and just like Windows, new builds will also appear going forward. TVL Nicolas --~--~-~--~~~---~--~~ 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: Dev Channel Release 3.0.184.0 from r17859
On Mon, Jun 8, 2009 at 2:29 PM, Jon j...@chromium.org wrote: We are using r17859 as the branch point for the 184 branch. If you know of any significant regressions around this branch please reply to this email with the bug number. If there isn't a bug number then create one and reply with it. You need to merge r17891 for crbug.com/13428 (nasty regression in build 183). 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: HTTP POST via net package?
On Mon, Jun 8, 2009 at 2:02 PM, Daniel Cowxdaniel.c...@gmail.com wrote: How can I upload multipart form data (including a file) via HTTP POST? Is there something already written in the net package (or elsewhere) for this task? If so, can someone please point me to what class to use. You can use the URLRequest class in the net package to do HTTP POST. The URLFetcher class in chrome/browser/net is good example code. You can also use url_request_unittest.cc as example code. Wan-Teh --~--~-~--~~~---~--~~ 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: HTTP POST via net package?
If you're interested in seeing the multipart form data encoder, that's in WebCore. WebCore/platform/network/FormData.cpp h WebCore/platform/network/FormDataBuilder.cpp h In Chrome, the webcore FormData data type is translated to a chrome net::UploadData structure in WebRequestImpl::GetUploadData. The net package doesn't know about multipart form encoding... just UploadData structures. On Mon, Jun 8, 2009 at 3:11 PM, Wan-Teh Chang w...@google.com wrote: On Mon, Jun 8, 2009 at 2:02 PM, Daniel Cowxdaniel.c...@gmail.com wrote: How can I upload multipart form data (including a file) via HTTP POST? Is there something already written in the net package (or elsewhere) for this task? If so, can someone please point me to what class to use. You can use the URLRequest class in the net package to do HTTP POST. The URLFetcher class in chrome/browser/net is good example code. You can also use url_request_unittest.cc as example code. Wan-Teh --~--~-~--~~~---~--~~ 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: What is the best way to get document location from an NPAPI plugin?
I'm surprised that GetURL on window.location works for the
npapi_uitest.cc GetURL()...
I finally realized that it has to do with the fact that
window.location and document.location are objects and they weren't
being automatically converted to strings in the code path above. When
I try either window.location.href or document.location.href both of
them work perfectly fine and I get the string delivered via a new
stream. I haven't traced back to the changes that are causing this but
this kind of makes sense and is certainly a much simpler solution than
the npruntime route (which does also work for me incidentally).
On Jun 8, 1:51 pm, John Abd-El-Malek j...@chromium.org wrote:
Perhaps try javascript:window.location. We have a test for this in
npapi_uitest.cc: GetURL, and it uses window.location successfully.
On Mon, Jun 8, 2009 at 1:29 PM, vijay tec...@gmail.com wrote:
Hmm... I'm not exactly sure how Flash works (are there any pointers
to this or do you figure this just by debugging Flash with Chrome?)
but here's the specific problem I'm running into.
We used to use NPN_GetURL with javascript:document.location as the
URL. In the current implementation, after this script is executed in
WebPluginImpl::ExecuteScript (in src/webkit/glue/webplugin_impl.cc),
its checking the result value:
WebCore::ScriptValue result =
frame()-loader()-executeScript(script_str, popups_allowed);
WebCore::String script_result;
std::wstring wresult;
bool succ = false;
if (result.getString(script_result)) {
succ = true;
wresult = webkit_glue::StringToStdWString(script_result);
}
For the above javascript I'm using, the result is false and I'm not
sure why. Because of that, eventually in the
PluginInstance::SendJavaScriptStream, no stream is being created at
all. As I mentioned before this used to work with Chrome 1.x. I'm not
sure why the javascript document.location does not correctly result in
a string. I probably need to dig in more. Does this exact sequence
work correctly for you?
Thanks for all your time btw!
Vijay
On Jun 8, 11:15 am, John Abd-El-Malek j...@chromium.org wrote:
Are you sure this is broken? Flash uses this so if it was broken, we
would
have seen lots of sites fail.
On a debug build, I can see this working fine using about:ipc.
NPN_GetProperty is called on location
and the returned object is NPN_Invoke'd to call toString
On Mon, Jun 8, 2009 at 1:38 AM, vijay tec...@gmail.com wrote:
Yeah. Here is what worked for us in the past: we issue a NPN_GetURL
with javascript:document.location and the browser simply delivered
the location via the standard NPP_NewStream, NPP_Write, etc. This
works perfectly with mozilla/firefox. It also used to work the same
exact way in Chrome 1.x so our code worked without any problems.
However, with Chrome 2.0 (and the webkit underneath it), there were
some changes and the javascript results are not being delivered via
streams any more. Chrome/webkit is simply executing the javascript and
ignoring the results. I can't say I agree with the rationale behind
the change but it seems to have killed about the simplest way to get
the document location :)
On Jun 7, 11:29 pm, Adam Barth aba...@chromium.org wrote:
This turns out to be very trick to do securely. I recommend studying
how Flash does this and doing *precisely* the same thing.
Adam
On Sun, Jun 7, 2009 at 10:57 PM, vijaytec...@gmail.com wrote:
Preferably a browser-independent way would be great.
Thanks in advance,
Vijay
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Fixing our keyboard handling act on OSX
Hi Hironori, Upon further reflection, I'm concerned about some of the fixes around these issues interacting badly with the Cocoa restructuring work I'm doing. Could you hold off on the OSX side of the changes till the end of the month to give me time to transition the Mac infrastructure to work better with Cocoa? Best regards, Jeremy 2009/6/7 Jeremy Moskovich jer...@chromium.org Hi Hironori, Thanks for the detailed report. I haven't nearly the same insight into the text input system as you and Avi do, but from what I've seen it may be possible for us to do at least a marginally better job using the built-in system routines and thus avoiding many sticky bugs e.g. http://crbug.com/10862 - OS X: Can't use command-key shortcuts with foreign keyboard layouts should be fixed by a CL I'm working on at the moment. The solution is to go through the native Cocoa methods to have the menu item fire the appropriate objc selector on the RHWV rather than trying to process the raw keystroke in the renderer process. I also think we can get Cocoa to translate emacs editing commands (such as cntrl-a) into the appropriate WebKit editor commands for us. Best regards, Jeremy 2009/6/5 Hironori Bono (坊野 博典) hb...@chromium.org Hi Jeremy, et al, Sorry for my slow update. This is the draft report of my investigation that implements the NSTextInput protocol on Mac, implements the GtkIMContext on Linux and observes keyboard events on Windows, Mac, and Linux. (Sorry, I would like to send it as a PDF file because the google site somehow compresses its figures too much to make its characters unreadable.) Since I'm still finding the best solutions for the issues, any comments and suggestions are definitely welcome. Regards, Hironori Bono E-mail: hb...@chromium.org 2009/5/29 Hironori Bono (坊野 博典) hb...@chromium.org: Hi Jeremy, I have been investigating keyboard events on Windows, Linux, and Mac to find solutions for these issues. Shall we have a discussion about these issues when I finish writing my report (maybe sometime next week)? Regards, Hironori Bono E-mail: hb...@chromium.org On Thu, May 28, 2009 at 7:14 AM, Jeremy Moskovich jer...@chromium.org wrote: Hi All, We currently fudge our keyboard handling on OSX, we interpret command key shortcuts ourselves and thus miss out on quite a few Cocoa text handling niceities. We also don't support IMEs. Relevant bugs: http://crbug.com/10862 - OS X: Can't use command-key shortcuts with foreign keyboard layouts http://crbug.com/12698 - standard macintosh text editing keyboard shortcuts are missing http://crbug.com/11981 - Deadkeys do not work http://crbug.com/11952 - IME support (Chinese input method doesnt work) We also don't handle activation/deactivation of edit menu items correctly (select all is always disabled). I've done a little digging in WebKit's keyboard handling and what follows is a proposal on how we can more closely match the OSX keyboard handling code and [hopefully] do things the right way. I don't purport to understand this all and there may be simpler ways to achieve this so feel free to comment. Standard commands (Copy/Paste/Select-all): WebKit handles these through the regular obj-c selectors in WebHTMLView, see the WEBCORE_COMMAND macro. We could do the same thing and add these selectors to BrowserWindowController which would then send an IPC message over to the renderer process to execute the appropriate command. The tricky bit is updating the menus, the model in Cocoa is for the OS to call you for each menu item before displaying a menu. We can't block the browser process on the renderer process so the browser process would always need to know if there is an active selection. WebCore appears to already have a mechanism to do this via notifyAccessibilityForSelectionChange() - we could use the same or a similar mechanism to send an IPC message back to the browser process each time the selection changes. Emacs keyboard commands and IMEs: The IME part of the title may be nonsense, but looking at the code it appears the code path and issues are the same. I've attached the stack trace for hitting cntrl-t to the end of this email. The tricky bit here is that WebCore is first given a shot at handling the event and then passes it back to WebHTMLView to take another look at the event which is where it's actually parsed. I assume this is to give JS code a chance to listen on these events. Since we can't serialize an NSEvent, we can't replicate this code solely in the renderer. A possible solution to this would be to store a queue of the last N NSEvents per renderer matched with an ID. the event would then be serialized and sent to the renderer which could then send it's own IPC message back to the browser process to get Cocoa to handle the message, we could pick the NSEvent out of the
[chromium-dev] Re: Zygote mode on by default in Linux now. Here's how to disable it...
On Mon, Jun 8, 2009 at 5:39 PM, Dan Kegeldaniel.r.ke...@gmail.com wrote: If for some reason (say, you don't like the fact that the main process is now this funky fork server) you want to go back to how things were before temporarily, you can disable zygote mode by doing export DISABLE_ZYGOTE_MANAGER=x before running. (Note, I'll be changing this shortly to be based on a command line flag. Also, I'll make --renderer-cmd-prefix work again). 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: Fixing our keyboard handling act on OSX
Hi Jeremy, It is not a problem at all. Thank you for notifying this. Regards, Hironori Bono E-mail: hb...@chromium.org 2009/6/9 Jeremy Moskovich jer...@chromium.org: Hi Hironori, Upon further reflection, I'm concerned about some of the fixes around these issues interacting badly with the Cocoa restructuring work I'm doing. Could you hold off on the OSX side of the changes till the end of the month to give me time to transition the Mac infrastructure to work better with Cocoa? Best regards, Jeremy 2009/6/7 Jeremy Moskovich jer...@chromium.org Hi Hironori, Thanks for the detailed report. I haven't nearly the same insight into the text input system as you and Avi do, but from what I've seen it may be possible for us to do at least a marginally better job using the built-in system routines and thus avoiding many sticky bugs e.g. http://crbug.com/10862 - OS X: Can't use command-key shortcuts with foreign keyboard layouts should be fixed by a CL I'm working on at the moment. The solution is to go through the native Cocoa methods to have the menu item fire the appropriate objc selector on the RHWV rather than trying to process the raw keystroke in the renderer process. I also think we can get Cocoa to translate emacs editing commands (such as cntrl-a) into the appropriate WebKit editor commands for us. Best regards, Jeremy 2009/6/5 Hironori Bono (坊野 博典) hb...@chromium.org Hi Jeremy, et al, Sorry for my slow update. This is the draft report of my investigation that implements the NSTextInput protocol on Mac, implements the GtkIMContext on Linux and observes keyboard events on Windows, Mac, and Linux. (Sorry, I would like to send it as a PDF file because the google site somehow compresses its figures too much to make its characters unreadable.) Since I'm still finding the best solutions for the issues, any comments and suggestions are definitely welcome. Regards, Hironori Bono E-mail: hb...@chromium.org 2009/5/29 Hironori Bono (坊野 博典) hb...@chromium.org: Hi Jeremy, I have been investigating keyboard events on Windows, Linux, and Mac to find solutions for these issues. Shall we have a discussion about these issues when I finish writing my report (maybe sometime next week)? Regards, Hironori Bono E-mail: hb...@chromium.org On Thu, May 28, 2009 at 7:14 AM, Jeremy Moskovich jer...@chromium.org wrote: Hi All, We currently fudge our keyboard handling on OSX, we interpret command key shortcuts ourselves and thus miss out on quite a few Cocoa text handling niceities. We also don't support IMEs. Relevant bugs: http://crbug.com/10862 - OS X: Can't use command-key shortcuts with foreign keyboard layouts http://crbug.com/12698 - standard macintosh text editing keyboard shortcuts are missing http://crbug.com/11981 - Deadkeys do not work http://crbug.com/11952 - IME support (Chinese input method doesnt work) We also don't handle activation/deactivation of edit menu items correctly (select all is always disabled). I've done a little digging in WebKit's keyboard handling and what follows is a proposal on how we can more closely match the OSX keyboard handling code and [hopefully] do things the right way. I don't purport to understand this all and there may be simpler ways to achieve this so feel free to comment. Standard commands (Copy/Paste/Select-all): WebKit handles these through the regular obj-c selectors in WebHTMLView, see the WEBCORE_COMMAND macro. We could do the same thing and add these selectors to BrowserWindowController which would then send an IPC message over to the renderer process to execute the appropriate command. The tricky bit is updating the menus, the model in Cocoa is for the OS to call you for each menu item before displaying a menu. We can't block the browser process on the renderer process so the browser process would always need to know if there is an active selection. WebCore appears to already have a mechanism to do this via notifyAccessibilityForSelectionChange() - we could use the same or a similar mechanism to send an IPC message back to the browser process each time the selection changes. Emacs keyboard commands and IMEs: The IME part of the title may be nonsense, but looking at the code it appears the code path and issues are the same. I've attached the stack trace for hitting cntrl-t to the end of this email. The tricky bit here is that WebCore is first given a shot at handling the event and then passes it back to WebHTMLView to take another look at the event which is where it's actually parsed. I assume this is to give JS code a chance to listen on these events. Since we can't serialize an NSEvent, we can't replicate this code solely in the renderer. A possible solution to this would be to store a queue of the last N NSEvents per renderer matched with an ID. the event
