Hacker News Reader

Comment by dumbmatter | Hacker News Reader

What are we supposed to do about stuff this? Like I wrote a video game https://play.basketball-gm.com/ that lets you open multiple tabs for viewing multiple screens even while simulation is occurring in another tab. But Chrome recently stopped running the simulation if it's in a background tab. Putting my simulation code in a Shared Worker would be nice, except Safari and IE will never support it and it seems likely to be deprecated soon. Service Workers kill anything that takes over 30 seconds, so no long running processing allowed. What do I do? Go back to writing desktop apps that nobody will install?

View on HN

It would be dodgy hack, but another HN comment made reference to a statement that tabs playing audio are always considered "foregrounded": https://groups.google.com/a/chromium.org/forum/#!topic/blink...

I think I might actually try this lol

...that would explain why flash files with no sound seem to 'pause' (or at least, run very, very slowly) when in a different tab.

Their own Google Play would be impacted otherwise. Good to hear, since the only thing I use Chrome for is Google Play (and any other, one-off, old-fashioned sites which require Flash). Why in the world does Google still require Flash for... anything?

Great, so we can now expect more and more sites to start playing "null" audio as a "workaround".

Iframe them onto one page and make the browser window huge. Something like:

    <iframe src="the url" width="50%" height="50%">
    <iframe src="the url" width="50%" height="50%">
    <iframe src="the url" width="50%" height="50%">
    <iframe src="the url" width="50%" height="50%">

There's also the <frameset> and <frame> tags to divide pages between URLs.

This isn't a full solution, but perhaps inter-tab communication would work? Use whichever tab is focused as the master, then other tabs send messages to the primary as they need work done. It wouldn't work when none of your tabs are focused, but perhaps that's an acceptable constraint.

That might work, but it's much more complicated and given the issues I'm already facing, I wouldn't want to rely on that communication actually happening (maybe background tab won't be able to send a signal to the foreground tab, since JS is apparently not running in the background tab).

Yes? I mean, you have to admit what you built is the epitome of edge case when it comes to how a browser is typically used, and is actually exactly the type of thing they want to optimize because basically if you aren't looking at the tab, it's not being used (generally).

Maybe use electron or something?

I don't think that replacing a traditional desktop app with a web app is an edge case. That's one of the main points of HTML5.

I think what was meant by edge case is how you've architected this. Going by a statement in another comment of yours:

> It is a pure SPA, you just have the option of opening multiple instances at the same time. Like I can open gmail in two tabs, but it's still an SPA.

Gmail just runs the UI in the browser though, the actual work of processing, receiving and sending mail is not done in a tab. The tabs are just views into the system.

It sounds like you are having one tab as both the client and the server, and separate tabs as clients to that other tab, which is pretty edge case.

As someone else suggested, you could move the processing to the server, but I imagine that's not feasible because then you are centralizing the processing and you're paying for processing, not the people visiting.

The more appropriate way to architect this (to my eyes, so take it for whatever you think it's worth) would be to use JS to manage tabs within the application (which you mentioned elsewhere already). The really simple way to implement this might be to have the JS tabs just contain an iframe to the prior implementation's real separate tab URL (since it already works that way, there's not likely to be any security issues you have to deal with).

The way you architected it is uncommon, though. For example, with GMail, that you mentioned as achieving a similar effect, server communication is involved.

As a developer you need to decide whether or not to support a browser, and if that browser doesn't provide the APIs you need then you should drop support for that feature in that browser. In this case, if Chrome is making a change that you can't or won't change your game for then the solution is to detect Chrome and display a "This game only works in a single tab in Chrome. Try Firefox!" message if a user opens it in a second tab.

It's your customers that generally dictate what browser you support.

If you don't support a browser, how do you learn whether its users are your customers?

Not if you have content or apps they really want.

I prefer Firefox, but since Google broke Google Voice (now Hangouts) plugin for FF users, I've been grudgingly opening a Chrome browser each time I want to make a phone call to US number.

Some people are in the fortunate position where they can choose to ignore large sections of their potential customer base. Someone who writes a game as (presumably) a side project is in exactly that position.

Make it a single page thing and spread the image out over multiple desktops. Make it a real desktop app instead. I do think Chrome / Google is (if they go through with this) actively going to fight against using the browser as an application platform though. At the very least they should give notifications to webapps that they are about to go to low-power mode, act differently when on a power cable, and check whether the tab is visible or not.

What are you supposed to do? Implement it as a single page application.

It is. But then you open it in multiple tabs, because that's how people use websites.

Unless I'm supposed to re-implement tabs within my single page application and then force it to only let one tab run, which I guess is possible but horrible :)

If it opens in multiple tabs, then it isn't a pure SPA. (Relying on the browser tabs instead of tabs in your application.)

If you have several tabbed views, then you would include tabs in your application.

It is a pure SPA, you just have the option of opening multiple instances at the same time. Like I can open gmail in two tabs, but it's still an SPA.

And yeah tabs in JS are possible and I might go down that route, it'll just be a lot of extra work to replicate a UI that already exists fine.

Here's an example: http://orteil.dashnet.org/cookieclicker/

Opening another tab creates a new bakery, not a view into the same bakery. (This only works if you haven't played before or clear your cookies.)

Edit:

If you really want to keep the same functionality then you would need to bring server communication into the mix. It's possible to either run the simulation server-side, or at least communicate the state between tabs using a server.

If you send an email in one Gmail window and it shows up in the other window, then I would guess it receives a message from the server to update.

The point still being, with this change you can have only one tab doing server communication at "full throttle", which may kill whatever gameplay elements make the players open this game in multiple tabs.

I'm not sure on the Chrome implementation, but I think all of the visible tabs would be foreground, not background. So the issue would be refreshing when changing tabs. (And also communicating between visible tabs).

The last time I played, opening a new tab would create a view into the same bakery, but it each tab diverged based on RNG. This allows you to cheat by, for example, taking multiple risk free chances at wrinkler drops.

chrome regulary breaks something, so we run tested versions of chrome for our internal webapp and block chrome updates.

but chrome does not like that and is always nagging and trying to trick you into installing the latest versions.

i looks like we will have to package it as electron app.

As a workaround, in the meantime, have you tried using several windows, not just tabs? Of course, none of them can be minimized, but they can be covered by other windows and should still run.

Nowadays, one writes ad-supported mobile games that nobody will pay for. ;)

Would it be possible to just declare "Best played in Firefox?" It's a bit gauche, but if a browser's engine has a behavior that isn't really compatible with what you intend to do, that's the browser's fault.

Could you create a tabbed interface that is just a dumb view of a server state communicated over websockets? Then the user could just open the page in n windows (each on its own tab) and have the same state represented in each?

Problem is, there is no server. All client side. So the tab on which you click "run simulation" is effectively the "server", except it stops running when the user switches tabs.

Put two of them in two iframes on the same page? No code changes should be needed

The fact that you don't have a backend is the limiting factor here.

In some ways it's limiting, but overall it's a good thing. Less complexity, less network transfer, works offline, etc. It's just more challenging to do in JS/HTML than in your choice of traditional desktop app dev tools.

GMail and Google Docs work offline too. Surely with things like Firebase it's less complex than inter-tab communication?

Oh, you’re volunteering to pay for it? How nice of you!

</sarcasm>

Cost is a real concern for these things. The tradeoff is running things on client or expensive backend or spending ages building a custom, efficient backend.

There are perfectly legitimate reasons to not have a backend. In fact, if something can be accomplished without user sending his data to some remote server (as opposed to just fetching data from the server), I believe it should be done this way.

What about split the simulation into small, < 30 seconds chunks?

Reply on news.ycombinator.com