It appears that Open is unused by the package. I'm guessing you added it for font loading before they were embedded? If it isn't required, removing it would also kill the dependency on "honnef.co/go/js/xhr".

Move existing code for setting canvas size to SetSize(). Maintains existing behavior of filling the browser window by default.

I'm not sure how to test this besides running it with a demo. It works for a tetris demo: https://github.com/Omustardo/tetris/tree/master/webgl-tetris

• Create ContextSwitcher interface.
• Require ContextSwitcher in Init.
• Allow use of arbitrary gl bindings by removing coupling with github.com/shurcooL/gogl.

Depends on https://go-review.googlesource.com/8793.

I've named it goglfw because I couldn't use the glfw name under my github username namespace, and I wanted to indicate that it's somehow different from normal glfw (i.e. it's a cross-platform package that works on desktop and in browser). However, despite the import path having base goglfw, the package is typically renamed glfw (import glfw ".../goglfw"), which makes things confusing.

Move it under https://github.com/goxjs namespace and rename it to glfw. So the new import path will be:

import "github.com/goxjs/glfw"

That'll solve both problems.

c_glfw-logs.zip $ go get -u github.com/goxjs/glfw

github.com/go-gl/glfw/v3.3/glfw

fatal error: error in backend: Segmented stacks do not support vararg functions. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /usr/bin/clang -I ../../go/src/github.com/go-gl/glfw/v3.3/glfw -fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build507152346/b002=/tmp/go-build -gno-record-gcc-switches -funwind-tables -I $WORK/b002/ -g -O2 -D_GLFW_X11 -D_GNU_SOURCE -fsplit-stack -o $WORK/b002/_x003.o -c c_glfw.cgo2.c

1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'c_glfw.cgo2.c'.
4. Running pass 'Prologue/Epilogue Insertion & Frame Finalization' on function '@_glfwInputError' #0 0x00000000022bcf54 PrintStackTraceSignalHandler(void*) (/usr/bin/clang+0x22bcf54) #1 0x00000000022bacde llvm::sys::RunSignalHandlers() (/usr/bin/clang+0x22bacde) #2 0x00000000022bc1fd llvm::sys::CleanupOnSignal(unsigned long) (/usr/bin/clang+0x22bc1fd) #3 0x000000000224db9a (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) (/usr/bin/clang+0x224db9a) #4 0x000000000224db3b (/usr/bin/clang+0x224db3b) #5 0x00000000022b748e (/usr/bin/clang+0x22b748e) #6 0x00000000009baf32 (/usr/bin/clang+0x9baf32) #7 0x000000000225133f llvm::report_fatal_error(llvm::Twine const&, bool) (/usr/bin/clang+0x225133f) #8 0x0000000002251218 (/usr/bin/clang+0x2251218) #9 0x00000000014e3357 llvm::X86FrameLowering::adjustForSegmentedStacks(llvm::MachineFunction&, llvm::MachineBasicBlock&) const (/usr/bin/clang+0x14e3357) #10 0x0000000001ac4043 (anonymous namespace)::PEI::runOnMachineFunction(llvm::MachineFunction&) (/usr/bin/clang+0x1ac4043) #11 0x00000000019f571e llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/bin/clang+0x19f571e) #12 0x0000000001cf8d39 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/bin/clang+0x1cf8d39) #13 0x0000000001cfe6d3 llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/bin/clang+0x1cfe6d3) #14 0x0000000001cf94eb llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/bin/clang+0x1cf94eb) #15 0x000000000247cd19 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_deletellvm::raw_pwrite_stream >) (/usr/bin/clang+0x247cd19) #16 0x0000000002f3db46 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/usr/bin/clang+0x2f3db46) #17 0x0000000003930133 clang::ParseAST(clang::Sema&, bool, bool) (/usr/bin/clang+0x3930133) #18 0x00000000029c4727 clang::FrontendAction::Execute() (/usr/bin/clang+0x29c4727) #19 0x00000000029607c1 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/bin/clang+0x29607c1) #20 0x0000000002a5d12a clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/bin/clang+0x2a5d12a) #21 0x00000000009babc7 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/bin/clang+0x9babc7) #22 0x00000000009b8eb1 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) (/usr/bin/clang+0x9b8eb1) #23 0x00000000028395a2 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optionalllvm::StringRef >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, bool) const::$_1>(long) (/usr/bin/clang+0x28395a2) #24 0x000000000224db1d llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/usr/bin/clang+0x224db1d) #25 0x0000000002838abf clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optionalllvm::StringRef >, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, bool) const (/usr/bin/clang+0x2838abf) #26 0x000000000280b32e clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const (/usr/bin/clang+0x280b32e) #27 0x000000000280b4d7 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) const (/usr/bin/clang+0x280b4d7) #28 0x0000000002821a08 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) (/usr/bin/clang+0x2821a08) #29 0x00000000009b893c main (/usr/bin/clang+0x9b893c) #30 0x00007f0a9d4130b3 __libc_start_main /build/glibc-ZN95T4/glibc-2.31/csu/../csu/libc-start.c:342:3 #31 0x00000000009b5f4e _start (/usr/bin/clang+0x9b5f4e) clang-11: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 11.0.0 (https://github.com/llvm/llvm-project.git 0160ad802e899c2922bc9b29564080c22eb0908c) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin clang-11: note: diagnostic msg:

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-11: note: diagnostic msg: /tmp/c_glfw-fa465c.c clang-11: note: diagnostic msg: /tmp/c_glfw-fa465c.sh

clang-11: note: diagnostic msg:

Hello. Caught this bug, while building your project:

c_glfw-logs.zip

This change is a work in progress on adding support for WebAssembly to package glfw, while maintaining GopherJS support.

It's done by differentiating code for WebAssembly (which uses syscall/js API) from existing code for GopherJS (which uses github.com/gopherjs/gopherjs/js API) with the following build constraints:

_js.go

// +build js,!wasm

... GopherJS code ...

_wasm.go

// +build js,wasm

... WebAssembly code ...

It has been developed and tested primarily with the Hover and eX0-go projects.

This PR implements the close callback via the browser's beforeunload event, which is fired just prior to the page being unloaded.

Note: We should mention there are some limitations on what the callback handler can do with the DOM depending on the browser. In some, opening a dialog is not allowed (to prevent annoying pop-ups).

Resolves #12.

This uses the browser's focus and blur events to implement the focus callback, which is informed when the browser window is in focus (active window) or not.

Depending on whether or not we want to consider multiple tabs as "all focused" or if each is focused individually, we may need to change the listener to attach to the document instead of the window. I have not explored browser functionality related to that.

Modern browsers implement the Page Visibility API which emits an event visibilitychange when a browser page is either hidden or made visible. The current visibility of a page can be found via document.hidden.

This can be used to implement the focus callback in the browser:

document.addEventListener('visibilitychange', (e) => focusCB(!document.hidden));

In comparison to the high level discussion of handling mouse wheel events in https://github.com/goxjs/glfw/issues/10 this issue is to look into specific instances of wheel event behavior.

The basic issue is that mouse "wheel" events provide extremely different delta values on different systems. At minimum browser, OS, and hardware are likely to play a role. For example, on Chrome+Win10, each step of a mouse scroll wheel results in a wheel event with delta value 120. On Firefox+Win10 the delta is 3.

The values goxjs/glfw is getting can be found manually for your system in the web console of: https://dmitri.shuralyov.com/projects/touch/scroll.html To see the base values that the system is sending to the browser, use gopherjs serve and navigate to: http://localhost:8080/github.com/goxjs/glfw/test/events/

A list of some values can be found here: http://stackoverflow.com/q/5527601/3184079