On 9/28/10 1:35 AM, timeless wrote:
On 9/28/10, Rob Evans<r...@mtn-i.com> wrote:
All good points. I think as we have moved away from simple web pages and
really start to think about applications that are coded in js, many things
previously the exclusive domain of desktop apps are more and more desirable
for web apps.
Unfortunately, moving away from simple pages introduces pain points
previously only experienced in desktop applications. Browser design
should aim to avoid exposing such pain points.
Complex apps necessarily introduce additional work.
What we're seeing, is that desktop application developers are now able
to use "web" APIs.
I also think that a web page should be able to request exclusive access to
the graphics card just like many native games do,
Many vendors are working hard to support WebGL. I don't think "exclusive
access" makes any sense,
but I'm not an expert. I recommend you review Google's work in the area,
as they're supporting
GL through various entry points (Native Client, WebGL, and their
OpenGL+DirectX layer).
I don't think that this issue has much to do with my proposal.
Only an application knows what should be done when backgrounded. But
some forms of backgrounding shouldn't really be exposed to apps. I
don't want an interstitial page to recognize that I'm ignoring it --
sadly, the future is in this direction, interactive ads which block
content views until they're dismissed.
window.onblur and window.onfocus already expose some of this.
Yes, the interactive ads now on YouTube and other services are quite
annoying,
and I'm sure the market will respond accordingly. But that's not a
standards nor security issue.
It'd be nice to know if Safari on iOS3 sends events to pages when the
user switches "away" and "back", I've assumed it just saves a picture
and reloads the page.
Safari task switching on iOS manages tabs by task switching, or reloading.
I don't know if it fires onfocus/onblur, but I'm sure it has some events.
WebApp developers targeting iOS may be running as an application using a
web frame.
The same is true for Android devs. They are always free to inject events
into their web frame;
was commonly done for events like "onorientationchange".
Imagine a user loads 2 html-canvas3d games. Imagine that the system
doesn't have much memory and that the user is paying for bandwidth
(I'm in .ie w/ .uk and .fi sims -- I'm roaming, it's expensive). Is
the user going to be happy with you trying to store your inactive game
in DOM/JS (which causes swapping) and then with you trying to use the
network as a storage? The right thing to do is to recognize your FPS
This sounds like something the game designer would put in their
settings. Just as
they currently do when allowing users to change resolution, depth,
lighting, and so forth.
unreliable/unusable for non browser applications (Maemo 5). At least
on Maemo 5 the low memory events (which were at least sort of used in
Maemo 4) are effectively never delivered. The system has 256mb of ram
(128mb is vaguely available to apps) and 764mb of swap (which prevents
low memory signals from being fired until after the system swaps to
I realize that low memory events may not be reliably received. We have
functioning
examples, however, of current browsers responding to low memory events.
So it can happen.
A programmer should not expect that they will reliably receive low
memory events.
The purpose is simply to expose them in cases they may happen in. Right
now, I hit low
memory issues in Chrome and Firefox, frequently. I'd like to throw in a
little extra code
to deal with that process.
Aza Raskin has put forward a great proof of concept of a web browser
running dozens
of tabs in a manageable UI. Whether a resource constrained system, or a
system that's
just running a hundred different processes, allowing hooks for
"onsuspend" "onlowmemory",
may mean that WebApp developers will support those conditions.
In the meantime, devs do code for those events, in non-standard ways,
through tool kits like Phonegap
guy determine where the risk point is. Typically what has happened for
perhaps 20 or more years in desktop/web applications is that low
memory conditions lead to "code execution vulnerabilities".
Chrome does a graceful crash of some running processes and not others.
It would
not introduce an attack vector to notify those still-running processes
with a dispatched event.
Anyway, for now, instead of pleading, please try working with what you
have. Once webworkers, taskmanagers, resource monitoring is exposed to
users, we can look into what should be exposed to apps. Please
remember that "the editor" will address threads eventually, but that
only new input (use cases, experience) is valuable.
Didn't realize it was pleading. I intended to have a conversation about
a proposal,
and whether the scope of that proposal should be extended.
As usual, in this mailing list, I'm sharing some of the demands and
experiences of my job,
hoping that others will discuss theirs with me, and that browser vendors
consider how those
use cases might be addressed in future versions.
Most of the browsers nowadays are open source; there's no need for pleading,
they have open processes to submit code patches for review.
-Charles
