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
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
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
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
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
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
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
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.
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
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
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
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)
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:
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
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
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
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
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
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
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
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
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.
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
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
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
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
26 matches
Mail list logo
