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.

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".

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

Summary

Because of browser limitations (to avoid websites abusing the Fullscreen API), requesting to enter fullscreen mode can only be done successfully during user input event handlers.

Therefore, when glfw.CreateWindow is called with fullscreen mode, we can only "schedule" the enter fullscreen request to occur at the next viable moment, which is when the user performs the next input event (mouse down, mouse up, keyboard down, or keyboard up events).

I'm not sure what can be done to improve this situation...

Details

Relevant excerpt from #gopherjs channel on Gophers Slack:

[3:20 AM] shurcool: So I was working on https://github.com/google/gxui/pull/86 just now, rebased it against latest master, etc. I saw there was a new sample demo, a fullscreen/windowed switcher

[3:21 AM] shurcool: I tried to implement it for the browser-side GLFW using Fullscreen API (https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Using_full_screen_mode)

Mozilla Developer Network
Using fullscreen mode
The fullscreen API provides an easy way for web content to be presented using the user's entire screen. This article provides information about using this API.

[3:21 AM] shurcool: but the problem is that browsers allow requesting to enter fullscreen mode only in user input callbacks.

[3:22 AM] shurcool: Now, the code to do that actually happens when the user clicks. But the problem is that due to goroutines, etc. it ends up being indirected and in reality it does not happen from the user click callback directly, and the browser fails the request. (edited)

[3:23 AM]
shurcool uploaded a file: 
Pasted image at 2015-05-28, 3:23 AM  
15KB PNG file • in #gopherjs  • Add comment • Open original


[3:43 AM] shurcool: I wonder what's a good way to go about solving this.

[3:46 AM] neelance: you’ll need to call it directly inside of the click handler, without wrapping it into a goroutine

[3:48 AM] neelance: this is similar to the `event.preventDefault()` problem

[3:48 AM] neelance: you also can’t do that inside of a new goroutine, because then it’s too late

[11:23 AM] shurcool: Yeah, I have an idea now. When doing `glfw.CreateWindow(..., fullscreen)` it can just set a boolean flag "requestedFullscreen" to true and the very next user input handler can actually perform the browser request.

[11:53 AM] neelance: gl :simple_smile:

----- Today May 29th, 2015 -----

[9:55 PM] shurcool: Okay, partial success (and the success part is _really_ cool!)

[9:56 PM] shurcool: The sample I'm testing this with has a big button "make fullscreen". When you press it, it goes fullscreen, and then the button becomes "make windowed".

[9:56 PM] shurcool: There are 2 ways to press the button. Focus it and press Enter or Space.

[9:56 PM] shurcool: When that key is pressed down (keydown event), it triggers.

[9:57 PM] shurcool: I've added my `if requestedFullscreen` checks into "keydown" and "keyup" listener events, and when you **release the key**, it catches that and goes fullscreen.

[9:57 PM] shurcool: So that part works, and it's awesome!

[9:57 PM] shurcool: But sadly, clicking with mouse is problematic.

[9:57 PM] shurcool: To trigger the button with mouse in gxui, you need to press mouse button and release the mouse button. It triggers on mouse button release event.

[9:58 PM] shurcool: The problem is that the browser "mouseup" event triggers event processing in gxui via goroutines, etc. and by the time it does glfw.CreateWindow(fullscreen) - "mouseup" has already finished earlier.

[9:59 PM] shurcool: So if the user presses the gxui button with mouse and waits - nothing happens. It will only go fullscreen the next time they click mouse or press key or do any "user event".

[9:59 PM] shurcool: :confused:

[10:01 PM]
shurcool uploaded a file: 
Fullscreen gxui sample working in browser via GopherJS and Fullscreen API.  
10KB PNG file • in #gopherjs  • Add comment • Open original


[10:19 PM] shurcool: I think this is the best I can do for now, so that's how it'll be... if anyone can think of a way to improve it (or if I think of something later), that'd be great!

This issue is to discuss the difference, and possible reconciliation, between mouse scrolling on different platforms and browsers.
Relevant code: https://github.com/goxjs/glfw/blob/master/browser.go#L234

When run on desktop, the scroll wheel has a delta of 1 per tick in my experience. When run in the browser I experience a delta of 10 per tick. It seems that the tick value also varies by browser according to:
http://stackoverflow.com/questions/5527601/normalizing-mousewheel-speed-across-browsers

Looking into it further, it appears my browser actually uses 120 per tick. http://phrogz.net/js/wheeldelta.html
Given the ideal of a single piece of code being able to run in the same fashion on both desktop and canvas, I suggest scroll wheel ticks be normalized to a delta of 1 per tick.

Possible solutions:

1. In the stack overflow link above, the top suggestion of simplifying the delta to -1, 0, or 1 seems reasonable at a glance, but based on comments it seems there are issues with different hardware like track pads that also uses the wheel event. It would also limit extremely fast scrolling to one tick per callback. I tested how often this might occur by spinning my mouse wheel as fast as I could manage while recording events in the chrome dev console. The most concentrated snippet of multiple events was:
   14 syscall.go:43 http:0: got scroll event: 0 -10
   syscall.go:43 http:0: got scroll event: 0 -20
   35 syscall.go:43 http:0: got scroll event: 0 -10
   syscall.go:43 http:0: got scroll event: 0 -20
   39 syscall.go:43 http:0: got scroll event: 0 -10
   syscall.go:43 http:0: got scroll event: 0 -20
   6 syscall.go:43 http:0: got scroll event: 0 -10
   syscall.go:43 http:0: got scroll event: 0 -20
   32 syscall.go:43 http:0: got scroll event: 0 -10
   The number of events with multiple mouse wheel ticks in a single callback is relatively small. It isn't negligible though.

2. Per browser support. Infeasible unless there's list that can be automatically kept up to date and imported statically.

3. http://stackoverflow.com/a/30134826/3184079
   Facebook published a solution licensed under BSD-3. Many of the stackoverflow comments recommend it, and it could be translated to Go without difficulty.
   https://github.com/facebook/fixed-data-table/blob/master/src/vendor_upstream/dom/normalizeWheel.js

4. Keep track of the smallest delta seen, and divide all others by its absolute value. Simple, but I don't know if it works in all cases.

I'm going to sleep on this and give it more thought.

This issue is to discuss how to think about and how to map the GLFW desktop concepts such as windows, resizing, monitors, fullscreen mode, etc., in the context of a browser. It resumes the discussion started in #8.

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 #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