[chromium-dev] Re: Build problems on build 149.30

2008-10-31 Thread Brett Wilson 

On Oct 31, 6:53 am, Lucila Sanjurjo [EMAIL PROTECTED] wrote:
 Thanks, I think maybe this version fails to compile.

 Last week I have synced to the last version of the code. This version seems
 to have an issue when pressing TAB key, it throws an access violation.

 void WebContentsViewWin::OnPaint(HDC junk_dc) {
   if (web_contents_-render_view_host() 
       !web_contents_-render_view_host()-IsRenderViewLive()) {
 ---
     if (!web_contents_-sad_tab_.get())
       web_contents_-sad_tab_.reset(new SadTabView);
     CRect cr;
     GetClientRect(cr);
     web_contents_-sad_tab_-SetBounds(gfx::Rect(cr));
     ChromeCanvasPaint canvas(GetHWND(), true);
     web_contents_-sad_tab_-ProcessPaint(canvas);
     return;
   }

 Looking at web_contents_ I can see that render_view_factory_ is NULL.
 This is a known issue?

Sync again. I broke this last week, it was broken for about half a
day, so you just got an unlucky build.

Brett
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Getting rid of toplevel scrollers?

2008-10-31 Thread Evan Martin 

On Fri, Oct 31, 2008 at 8:07 AM, Brett Wilson [EMAIL PROTECTED] wrote:
 My only idea at the moment is to draw my scrollers on top of the OS
 ones, but that would be a bad hack...

 Any better idea would be greatly appreciated.

 This isn't easily possible. WebKit handles all the scrollbars for all
 frames, which we implement in our graphics layer to make them look and
 act like Windows ones. You would have to go do a bunch of changes in
 this area to get the scrollbar to look differently.

Two hacky ideas:
1) Tell WebKit that the page is 4000px tall, then scroll the WebKit
widget's view.  I guess pages that examine their scrolloffset via
Javascript would break.
2) Use the CSS property overflow-y: hidden to force the scrollbars
off, then manage the scroll offset directly from your code.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Chrome cache system

2008-10-31 Thread Ricardo Vargas 
Now we have some documentation here:
http://sites.google.com/a/chromium.org/dev/developers/design-documents/disk-cache

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Design doc: Background Browser Task

2008-10-31 Thread [EMAIL PROTECTED] 

Thanks for your great feedbacks. Please see my comments below.

On Oct 29, 2:03 pm, Nick Baum [EMAIL PROTECTED] wrote:
 *Permissions:* I agree with Brian that drag-n-drop is somewhat clumsy for
 granting permissions (see how well that works for bookmarklets...). I'm
 syncing up with Mike Smith on this tomorrow, and Glen and I will work on a
 better
  solution.

We're still in active discussion on a better (more discoverable and
simple) opt-in mechanism. We're discussed click for permission dialog,
install wizard and drag-and-drop. Once we come to a better solution, I
will update the spec.

 Also, what happens next time I visit the app? Is it authorized to launch the
 background task, or do I have to re-authorize it?

When the background task is allowed to start, it will continue to run
even when the browser is exited. Next time when the system is started
and the user logs in, the background task will run automatically
without any re-authorization since the permission has already been
granted last time.

 *Lifetime:* Do we need the start on browser launch option? What's the use
 case for this?

We'll remove this option from the API. However, to address concern
from those people with limited bandwidth or lack of resource, the
browser can add an option to let the user choose between start-on-
login and start-on-browser-launch.


 *Process model:* Are there cases when a background task would need to
 communicate with the tab that created it? For example, opening an event in
 an existing calendar window.

Yes, the host page can talk to the background task through cross-
process MessagePort communication.

 Overall, this seems like a well thought-out proposal!

 -Nick

 On Wed, Oct 29, 2008 at 1:11 PM, Dmitry Titov [EMAIL PROTECTED] wrote:
  Good idea about OK delay...
  That part of the proposal is indeed the most controversial. Some folks love
  it, some hate it. Modal dialog can provide UI for learn more..., ask for
  specific permissions, perhaps even capture credentials to use while running
  in the background.  On the other side, Allow/Deny dialogs are sometimes
  bad because they basically shift blame to the user w/o transparency on
  what's going on.
  So we do expect opt-in mechanism will perhaps change - please voice any
  idea you like more.

  Dmitry

  On Tue, Oct 28, 2008 at 6:43 PM, Brian Rakowski [EMAIL PROTECTED]wrote:

  Drag and drop seems like a clumsy and unfamiliar mechanism for granting
  this capability. A modal dialog would be better. We can inject a delay on
  making the OK button active if we are worried about clever attacks that get
  users to click on an OK that appears underneath the cursor.
  -Brian

  On Tue, Oct 28, 2008 at 5:55 PM, [EMAIL PROTECTED] [EMAIL PROTECTED]
   wrote:

  Hi all,

  Here is a draft of a design doc for Background Browser Task:

 http://docs.google.com/View?docid=dd6rm2wb_3fmz8pnnp

  Your feedback is appreciated.

  Thanks,

  Jian
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---