Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should BrowserWindow.focus() fire focus event on JS window object? #26

Closed
kevinsawicki opened this issue Jun 14, 2013 · 3 comments
Closed

Should BrowserWindow.focus() fire focus event on JS window object? #26

kevinsawicki opened this issue Jun 14, 2013 · 3 comments

Comments

@kevinsawicki
Copy link
Contributor

@kevinsawicki kevinsawicki commented Jun 14, 2013

Currently it appears that calling remote.getCurrentWindow().focus() does not trigger a focus event to listeners bound using $(window).focus -> console.log 'focusing'.

Is this something atom-shell should do?

It is pretty easy to work-around it via atom/atom@772a990

@mutle
Copy link

@mutle mutle commented Jun 17, 2013

👍 on having atom-shell fire the callback to the window.

Loading

@zcbenz
Copy link
Member

@zcbenz zcbenz commented Jun 18, 2013

What if the focus is already on the devtools? Then calling remote.getCurrentWindow().focus() would force the focus to move from devtools to webview.

Loading

@zcbenz
Copy link
Member

@zcbenz zcbenz commented Jun 21, 2013

I'm now closing this issue because supporting it would have the side effect of making devtools lose focus, which may not be expected.

Loading

@zcbenz zcbenz closed this Jun 21, 2013
kevinsawicki pushed a commit that referenced this issue May 9, 2017
Get a basic Linux build working
kevinsawicki pushed a commit that referenced this issue May 9, 2017
Get a basic Linux build working
MarshallOfSound pushed a commit that referenced this issue May 1, 2018
It's not used anywhere. We use v8::TryCatch instead.
MarshallOfSound added a commit that referenced this issue Jun 27, 2018
* Initial commit.

* Do not rely on latest base/template_util.

* Enable modifying existing ObjectTemplate.

* Fix compilation error of function_template.

* Add initial Constructor type.

* Fix passing the wrong parameter.

* Make the Constructor accept arbitrary callback.

* Cleanup.

* Constructor should wrap the this pointer.

* Simplify Wrappable API.

* Remove helper typedefs.

* Support function with 7 parameters.

* Enable converting void*.

* Enable setting method in Dictionary.

* Add v8::Handle<v8::String> to converter.

* Make ScopedPersistent do type conversion.

* Add Arguments.Length method.

* Do not wrap an object when it's already wrapped.

* No need to reset wrapper_ when we would run destructor.

* Call object._init if we have one.

* Add object() accessor for Dictionary.

* Add converter for const char*.

* Enable creating empty Dictionary directly.

* Mark Dictionary.Get as const.

* Strictly check for boolean type.

* Add .gitignore.

* Add APIs to match new V8 APIs.

* Bring back ScopedPersistent.SetWeak.

* Some more APIs fixes.

* Reset handle in weak callback.

This doesn't seem to be neccesary, but we had better follow what upstream does.

* Enable converting ScopedPersistent.

* Fix compilation error with node 0.10.

* Fix compilation error of Constructor and ScopedPersistent in node 0.10.

* Use pump to generate source files.

* Add callback converter.

* Make ScopedPersistent's interface consistent with V8.

* Remove unused constructor of Dictionary.

* Add PersistentDictionary.

* Make throwing exception when parsing args easier

* Use NODE_VERSION_AT_LEAST to determine node version

* Don't throw error in Constructor

* Guard against non-constructor call in Constructor::New

* Fix throwing error in constructor

* Fix ignored exception thrown from constructor.

* OVERRIDE => override

* Avoid unnecessary copy in ConvertToV8

* Check internal field before converting

* Remove unneeded helper

* Add AfterInit method for Wrappable

* Add converter for unsigned long

* usigned long is uint64 on Linux

* Don't reset handle before Wrappable is destroyed

It is possible that the user wants to use the V8 object in the destructor.

Fixes #1112.

* added std::set converter

* Use Local instead of Handle

* Pass Handle to upper HandleScope when returning a V8 Handle

* Enter context before calling callback

* Allow converting Array

* Remember isolate in Wrappable

* Make isolate() public

* Check for null when converting Wrappable

* Add IsDestroyed method for Wrappable

* Allow specify methods that can be called after object is destroyed

* Use C++11 version of CreateFunctionTemplate

* Remove callback.h

* Remove locker.h

* Add Dictionary::CreateEmpty

* GetNext should have no side effect when failed

* Don't convert Function to Dictionary

* Don't pass callback as const reference

* Add SetHidden for Dictionary

* Use the new SetWeak in Wrappable

* Check whether key exists in Dictionary::Get

* Don't return v8::Maybe for std::vector

* Add Dictionary::Delete

* Do not manually destroy native resources

* isDestroy => isDestroyed

* Fix converter for std::set

* Improve error message for type error

Close #4307.

* Clear internal field when Wrapper is destroyed

* basic_types.h => macros.h

* use v8::private symbols as identifiers for object properties

* Make Wrappable a template class

* Leak Wrappable's template

Since it is declared as static variable it will be released
automatically when process exits, which causes crashes in
renderer process because the template will then be released
later than V8 is closed.

This commit simply leaks the template so the crash won't happen,
this leak should be fine since leaking resource on exit is not
a bad thing.

* Handle.ToV8 should return Object

* Add converter for std::map

* Setup v8::MicrotasksScope for callbacks

* Update to API changes of V8 5.2

* CHECK is not needed

* Call the user call Init in Constructor

* Make InitWith virtual

* Turn Wrappable into using FunctionTemplate

* Create objects from InstanceTemplate

* NewOperatorFactory is not used

* Remove the Constructor class

* GetConstructor should init default constructor

* Pass FunctionTemplate in BuildPrototype

* Do not set constructor name in SetConstructor

* Use ToDetailString for processing error message

* Add back empty handle string

* Add README

* create empty handle for null or undefined value

* Support setting read-only property value

* Add Converter<std::map<std::string, T>>::ToV8

* Add CI build through Electron

* Support 5 argument member function

* Use std functions instead of template_util

* Make Wrappable thread safe

* Use gin to manage FunctionTemplate

Sadly there is no way for us to know when V8 is closing, thus it is
impossible for us to clean the FunctionTemplate on exit at the right
time, which is critcal for multi-thread environment.

* add ability to set high memory usage, skipping the second round of GC callbacks

* Fix broken link

* Add a converter for `nullptr_t`

* Upstream Muon changes to avoid crashing

* only mark handle as independent when it's a high memory user

* Remove WrappableBase::GetWrapper() DCHECK

* virtual members need a virtual destructor

* GetWrapper should be const

* Add support for FreeBSD

* Remove usage of MarkIndependent api

https://bugs.chromium.org/p/chromium/issues/detail?id=780749
Use Active/Not Active as indicator whether the Scavenger can drop wrappers

* Address breaking API

* Fix Value::ToDetailString() call

See https://chromium-review.googlesource.com/848782

* Revert "Address breaking API"

This reverts commit e20cf86.

* Add mate::Promise

* Update travis settings

Use Node.js 9.7.0 and Xcode 9.3.

* Update appveyor settings

Use Visual Studio 2017.

* Remove mate::TryCatch (#26)

It's not used anywhere. We use v8::TryCatch instead.

* Address breaking API

* Don't copy things on Dictionary::Set

* Remove native_mate/compat.h

* prepare for merging to electron

* remove native_mate submodule

* update paths for native_mate

* move native_mate script to the electron scripts dir

* rename back to expected values

* fix linting
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants