summaryrefslogtreecommitdiffstats
path: root/chrome/browser/app_modal_dialog.cc
Commit message (Collapse)AuthorAgeFilesLines
* Whitespace change to trigger the bots.viettrungluu@chromium.org2010-08-161-1/+0
| | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/3167013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56188 0039d316-1c4b-4281-b951-d872f2087c98
* [Mac] augment modal cookie prompt on mac to include details panedanno@chromium.org2010-03-121-0/+4
| | | | | | | | | | | | | | | | Added two new xibs. The first is a cookie info view that is shared between the tree that shows browser data and the cookie modal prompt to block accepting cookies. The second is a window to replace the NSAlert modal dialog for the cookie prompt. Modified cookie tree code and added cookie prompt code to use new xibs. Changed "hidden" handling of cookie detail view to use bindings rather than explicit code. TODOs for http://crbug.com/36948 not in this CL: - changing the expiration for cookies isn't implemented TEST=manually testing of modal cookie prompt, new unit tests BUG=http://crbug.com/36948 Review URL: http://codereview.chromium.org/669127 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41408 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes two bugs in cookie prompting:sky@chromium.org2010-02-181-9/+0
| | | | | | | | | | | | | | | | | | . In certain situations we could crash because we weren't letting CookiePromptView::Init complete and then attempting to reference some NULL fields. I've fixed this by adding AppModalDialog::IsValid and moving the logic that was in Init to IsValid. This way we only create CookiePromptView when needed. . We were leaking AppModalDialogs. I've made CookiePromptView own the AppModalDialog and delete it when the CookiePromptView is deleted. BUG=36079 TEST=enable prompting for cookies, go to a bunch of sites make sure you don't crash. Review URL: http://codereview.chromium.org/632006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39328 0039d316-1c4b-4281-b951-d872f2087c98
* Refactored out JS specific part of modal dialog stack into its own class, ↵zelidrag@chromium.org2010-02-051-107/+10
| | | | | | | | | | | exposed cookie/storage prompt as a modal dialog. BUG=32719 TEST=none, requires Darin to hook this with his code. Review URL: http://codereview.chromium.org/560030 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38268 0039d316-1c4b-4281-b951-d872f2087c98
* [Mac] Wallpaper fix for crasher when an alert is called from an extension ↵andybons@chromium.org2010-01-211-0/+5
| | | | | | | | | | popup window. BUG=29355 TEST=none Review URL: http://codereview.chromium.org/552084 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36780 0039d316-1c4b-4281-b951-d872f2087c98
* Fix crash when an extension popup shows a JS alert. Showing the alert takes...rafaelw@chromium.org2009-11-241-23/+47
| | | | | | | | | | | | | | | | Landing this on for pam. Original issue: http://codereview.chromium.org/425011/show. Disable showing JS alerts from popups, because doing so makes the popup disappear immediately, which has all sorts of unfortunate side effects for the poor orphaned alert (see bug for details). BUG=27758 TEST=create extension with popup, put link with |onclick="alert('test');"| in it; install extension, open popup, and click link; see no crash (nor popup) Review URL: http://codereview.chromium.org/435010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32889 0039d316-1c4b-4281-b951-d872f2087c98
* Implement window.alert() and its cousins for extensions.pam@chromium.org2009-11-061-32/+30
| | | | | | | | | | | | Second try, now with fixed observer. BUG=12126 TEST=put a window.prompt() in a background page, a browser action, and a page action. Make sure it gets the result back correctly. Also make sure it still works when called from a web page. Review URL: http://codereview.chromium.org/373006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31204 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 31110 - Implement window.alert() and its cousins for extensions.ben@chromium.org2009-11-051-26/+24
| | | | | | | | | | | | | BUG=12126 TEST=put a window.prompt() in a background page, a browser action, and a page action. Make sure it gets the result back correctly. Also make sure it still works when called from a web page. Review URL: http://codereview.chromium.org/341089 TBR=pam@chromium.org Review URL: http://codereview.chromium.org/360063 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31126 0039d316-1c4b-4281-b951-d872f2087c98
* Implement window.alert() and its cousins for extensions.pam@chromium.org2009-11-051-24/+26
| | | | | | | | | | BUG=12126 TEST=put a window.prompt() in a background page, a browser action, and a page action. Make sure it gets the result back correctly. Also make sure it still works when called from a web page. Review URL: http://codereview.chromium.org/341089 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31110 0039d316-1c4b-4281-b951-d872f2087c98
* Fix deadlock when plugin puts an alert and right afterwards the browser ↵jam@chromium.org2009-09-281-4/+0
| | | | | | | | | | process makes a win32 call that ends up waiting on the plugin. Since the plugin thread is blocked, the Windows message doesn't get dispatched and the browser ui thread deadlocks. The message from the renderer would make the plugin run a nested message loop but it doesn't get run on the browser ui thread since it's blocked. The fix is to set the event that runs nested message loop in the renderer process. BUG=23147 TEST=ui tests already cover nested message loops and plugins. This particular scenario is hard to write a test case for because it's a race condition involving the browser. Review URL: http://codereview.chromium.org/243018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27421 0039d316-1c4b-4281-b951-d872f2087c98
* Split the IPC code into ipc/agl@chromium.org2009-07-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This splits the ipc code from the common project. The 'common' project pulls in all of webkit, the v8 bindings, skia, googleurl, and a number of other projects which makes it very difficult to deal with especially for external projects wanting just to use some of Chromium's infrastructure. This puts the ipc code into its top-level ipc/ directory with a dependency only on base. The common project depends on the new ipc/ipc.gyp:ipc target so that all projects currently pulling common in to get the IPC code still have it available. This mostly follows agl's pre-gyp attempt to do this which was r13062. Known issues: - Currently a number of projects depend on chrome/chrome.gyp:common in order to use the IPC infrastructure. Rather than fixing all of these dependencies I have made common depend on ipc/ipc.gyp:ipc and added "ipc" to the include_rules section of DEPS so that checkdeps.py doesn't complain. Over time projects that need IPC should depend on the IPC project themselves and dependencies on common removed, although I don't think many projects that need IPC will be able to get away without common currently. - ipc/ipc_message_macros.h still has #include "chrome/common/..." inside of a ipc/ should not refer to files in chrome/... now. I'm not sure how to resolve this since it's really an IDE bug - the named pipe name (windows+linux) and the logging event name (all) + env variable (posix) refer explicitly to 'Chrome' which somewhat hurts the illusion of ipc/ being an independent library. I think this should be examined in a subsequent, much smaller patch. - I've eliminated the IPC.SendMsgCount counter since it was implemented in a way to create a dependency from ipc/ to chrome/common/chrome_counters. This is the same approach that r13062 took. http://codereview.chromium.org/155905 (Patch from James Robinson) git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21342 0039d316-1c4b-4281-b951-d872f2087c98
* Convert JavascriptAlertActivatesTab to browser_tests framework.phajdan.jr@chromium.org2009-07-101-3/+21
| | | | | | | | | | | | This should make it non-flaky, so I un-disabled the test. I also added necessary plumbing so we can wait for AppModalDialog to appear and close it. TEST=Covered by browser_tests. http://crbug.com/16062 Review URL: http://codereview.chromium.org/149460 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20400 0039d316-1c4b-4281-b951-d872f2087c98
* This CL is a clean-up of the app_modal_dialog_queue.cc in an attempt to fix ↵jcampan@chromium.org2009-05-281-4/+5
| | | | | | | | | | | | | | a bug 10699. Not sure what is causing the crasher. Hopefully after this clean-up we'll get a different stack-trace that might help. BUG=10699 TEST=Make sure alert/confirm boxes work properly. make sure a background tab that shows a (delayed) alert box works. Same with a background browser. Review URL: http://codereview.chromium.org/113932 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17078 0039d316-1c4b-4281-b951-d872f2087c98
* Displaying consecutive alerts from plugins should not hang the browser. The ↵ananta@chromium.org2009-05-151-0/+6
| | | | | | | | | | | | | | | | | | plugins display alerts via the NPN_Evaluate API. The browser signals an event handle to ensure that the plugin starts peeking for messages while waiting for the NPN_Evaluate call to return. When the dialog is dismissed by the user, windows does send some messages to the plugin window underneath, like activation messages, etc. These don't get dispatched as the event is reset when the dialog is dismissed, i.e. much before the window is actually destroyed. The fix is to reset the event handle after the window is actually destroyed. To achieve this I added an OnClose virtual function to the DialogDelegate interface, which is overridden by the JavascriptMessageBoxDialog class which eventually ensures that the event is reset. This fixes http://code.google.com/p/chromium/issues/detail?id=10799 I updated the AlertInWindowMessage npapi test to display two alerts instead of one. Bug=10799 Review URL: http://codereview.chromium.org/113464 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16172 0039d316-1c4b-4281-b951-d872f2087c98
* Replace all occurrances of WebContents with TabContents.brettw@chromium.org2009-05-041-17/+17
| | | | | | Review URL: http://codereview.chromium.org/99177 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15194 0039d316-1c4b-4281-b951-d872f2087c98
* Re-land my change to clean up TabContents/WebContents ownership. Thisbrettw@chromium.org2009-04-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | is the same except in tab_strip_model_unittest I fixed a leak by making a WebContents on the stack, I added a factory to the SiteInstance unittest to prevent another leak, and I re-added a NULL set to the external_tab_container. Fix the ownership model of TabContents and NavigationController. Previously the NavigationController owned the TabContents, and there were extra steps required at creation and destruction to clean everything up properly. NavigationController is now a member of TabContents, and there is no setup or tear down necessary other than the constructor and destructor. I could remove the tab contents creation in the NavigationController, as well as all the weird destruction code in WebContents which got moved to the destructor. I made the controller getter return a reference since the ownership is clear and there is no possibility of NULL. This required changing a lot of tiles, but many of them were simplified since they no longer have to NULL check. Previous review URL: http://codereview.chromium.org/69043 Review URL: http://codereview.chromium.org/67294 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14053 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 14005.brettw@chromium.org2009-04-181-2/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14006 0039d316-1c4b-4281-b951-d872f2087c98
* Fix the ownership model of TabContents and NavigationController. Previously thebrettw@chromium.org2009-04-181-1/+2
| | | | | | | | | | | | | | | | | NavigationController owned the TabContents, and there were extra steps required at creation and destruction to clean everything up properly. NavigationController is now a member of TabContents, and there is no setup or tear down necessary other than the constructor and destructor. I could remove the tab contents creation in the NavigationController, as well as all the weird destruction code in WebContents which got moved to the destructor. I made the controller getter return a reference since the ownership is clear and there is no possibility of NULL. This required changing a lot of tiles, but many of them were simplified since they no longer have to NULL check. Review URL: http://codereview.chromium.org/69043 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14005 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor AppModalDialogQueue and move JS Alert boxes into a MVC.tc@google.com2009-04-071-0/+99
JavascriptMessageBoxHandler (handles alert, confirm, prompt, and onbeforeunload) was a views class. This change converts it into an MVC so we can port to linux/mac. AppModalDialog is the model+controller, JavascriptMessageBoxDialog is the windows specific view. The onbeforeunload dialog (JavascriptBeforeUnloadHandler) was a subclass of JavascriptMessageBoxHandler that had a different title and button text. I merged this class into JavascriptMessageBoxHandler by passing a bool to handle the custom button text. Review URL: http://codereview.chromium.org/63033 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13276 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-01 07:00:50 +0000