Aggressive web sites -- suggestion Topic is solved

[markfilipak]

Not possible.

You might dream the solution. That's what happens to me when I'm designing hardware. I go to bed thinking of the problem and in the morning, I have the solution. I'll cross my fingers.

All the Best, and Thanks for Pale Moon,
Mark.

[Moonchild]

No, you don't understand. It's simply not possible. If the browser process hangs, it hangs. A UI button won't help because it won't be able to interact with a hanging engine. Neither will an external program (even less so).

[markfilipak]

No, you don't understand. It's simply not possible. If the browser process hangs, it hangs. A UI button won't help because it won't be able to interact with a hanging engine. Neither will an external program (even less so).

Sure it's possible, MC. Preemptive dispatchers do it all the time. If a task is non-responding, the dispatcher kills it. What I'm suggesting is that instead of killing, the dispatcher put up a control so that the user can decide whether to kill and what to kill. The user knows what tab (or window) is screwing up.

[Moonchild]

... Well, I guess you seem to know the inner workings of the browser better than I do then, if you correct me like that.

Go ahead and fix it then. I'll be waiting.

[markfilipak]

... Well, I guess you seem to know the inner workings of the browser better than I do then, if you correct me like that.

Go ahead and fix it then. I'll be waiting.

You have misinterpreted my suggestions for corrections. They're not corrections. They are suggestions that go beyond what would normally be needed for a single-threaded application, but suggestions that I think will work and that you might find useful for other things, too. Take whatever you want from the suggestions, or take nothing, or ask me to explain what I refer to. I'd be happy to explain for however long it takes.

Warm Regards,
Mark.

[vannilla]

An external process would not be able to kill a hanging program because the program would not be able to process the signal unless it's one of those signals that always take effect like SIGKILL, but at that point you can just use the "kill" (or "killall") tool to send the SIGKILL signal when the program hangs instead of devising a convoluted daemon which tracks the browser's state (a feat that might not even be possible.)
As for a UI button directly inside the browser, as Moonchild said, if the browser hangs so does the UI, meaning you would not be able to even press the button, let alone make it work.
A UI button outside the browser is just like using "kill", except that it will first try to "gently kill" the program and only after a timeout it will prompt the user asking if it's ok to brutally terminate the program.
Note: obviously here I'm talking about Linux, but the same applies to Windows, just with different names and slightly different behaviour.

[markfilipak]

An external process would not be able to kill a hanging program ...

Agreed. That's why it cannot be an external process. In my own clumsy way I'm suggesting that an executive that launches the main PM app and handles mallocs & forks on a per-tab basis (as a service to the main PM app), would then have the power to kill on a per-tab basis by freeing bound memory & closing the offending tab via brute force (and with user identification of which tab is the offending tab ...something the user will absolutely know). For the executive, I favor Mealy-Moore state machines

Code: Select all

while(true) {
switch(currentState) {
case 1: switch(inputs) { case 1: outputs=...; break; case 2: outputs=...; break; case 3: outputs=...; break; etc.} currentState=...; break;
case 2: switch(inputs) { case 1: outputs=...; break; case 2: outputs=...; break; case 3: outputs=...; break; etc.} currentState=...; break;
case 3: switch(inputs) { case 1: outputs=...; break; case 2: outputs=...; break; case 3: outputs=...; break; etc.} currentState=...; break;
etc.
}
}

but I appreciate that a state machine executive might be hard to shoehorn into existing code (but I think that it would be worth the development, and that it's what Firefox is working toward -- though they've bollixed the UI along the way). In any event, the executive wouldn't have to be a state machine; I just favor state machines for their 100% code coverage and 100% testability (plus the bonus that, when you're done coding, you know you're done and that there will be no unpleasant surprises in the future).

As for a UI button directly inside the browser ...

Unfeasible, I agree. But if the executive held the 'kill' buttons up to the user ...

A UI button outside the browser is just like using "kill" ...

I agree again. I can already use the System Monitor to kill the whole application. Killing the whole application is painful and provokes a selective restore when relaunched. The trick I'm proposing is to kill offending tabs on a per-tab basis (with help from the user).

PS: The 'killing' can be handled on an event-basis with the event being the user selection of which tab to 'kill', so I think it's feasible.

PPS: Just to clarify, the 'kill' buttons would be always displayed, not dependent on a timeout. What to 'kill' and when to 'kill' would be left to user judgment.

[Moonchild]

So, basically what you want is a multi-process setup, with one process for each open tab. You might want to think about using a different browser then...

[markfilipak]

So, basically what you want is a multi-process setup, with one process for each open tab. You might want to think about using a different browser then...

I can understand why you would think that. Actually, that would be inefficient. All tabs could be serviced via a service loop: while(true) { }. Only one tab will have focus and the others would simply 'return'.

[doofy]

So, basically what you want is a multi-process setup, with one process for each open tab. You might want to think about using a different browser then...

I can understand why you would think that. Actually, that would be inefficient. All tabs could be serviced via a service loop: while(true) { }. Only one tab will have focus and the others would simply 'return'.

I have no idea what you are talking about.
And I suspect that if you offered MC a solution to the prob that you perceive, then MC would consider it.
MC has already told you he will look at your fix.

FFS - I can tell MC how to improve his browser; don't mean jack shit without boots on the ground.

[Moonchild]

I can understand why you would think that. Actually, that would be inefficient. All tabs could be serviced via a service loop: while(true) { }. Only one tab will have focus and the others would simply 'return'.

That doesn't work. Pages that are open in the background need processing of events for their scripting or they will break. Not to mention things like media. A tab "having focus" doesn't mean "all other tabs are frozen".

[markfilipak]

I can understand why you would think that. Actually, that would be inefficient. All tabs could be serviced via a service loop: while(true) { }. Only one tab will have focus and the others would simply 'return'.

That doesn't work. Pages that are open in the background need processing of events for their scripting or they will break. Not to mention things like media. A tab "having focus" doesn't mean "all other tabs are frozen".

Okay. That doesn't matter. The point is that all tabs can be serviced serially; multi-threading of the individual tabs is not required.

[Moonchild]

You should probably read some material to understand how Javascript tasks and queues work. This isn't Java or C, things on threads can't be suspended and then resumed. JS is primarily event driven through an event loop.

Keep in mind that the browser application itself is also JS driven.

https://developer.mozilla.org/en-US/doc ... /EventLoop

[markfilipak]

You should probably read some material to understand how Javascript tasks and queues work. This isn't Java or C, things on threads can't be suspended and then resumed. JS is primarily event driven through an event loop.

Keep in mind that the browser application itself is also JS driven.

https://developer.mozilla.org/en-US/doc ... /EventLoop

Ah! I thought PM was written in 'C'. Javascript, eh? That does change things. I've written some js, about 8- or 9-thousand lines including a full-on WinXP emulator with real-looking, XP controls that pushed in -- remember those days? -- and dragable, resizeable windows with emulated focus & visual sorting with new window creation and web-page populating, etc. and even 2- & 3- column layout (like a book) done automagically with columns automatically balanced -- I was especially proud of them. I layed everything out hidden, then measured them in the DOM, then shuffled the text around and unhid them when the columns were balanced. It was crazy hard but fun.

I'll have to think on whether js can do what I'm describing. My 1st reaction is "No", but I'll think on it.

Thanks for the info, MC.

PS: I'll do more than think on it. I'll write some demo code. It will be awhile, though.

[New Tobin Paradigm]

Unified XUL Applications are written in many things.

[markfilipak]

... https://developer.mozilla.org/en-US/doc ... /EventLoop

I know how to create fully interactive pages within browsers (which is the subject of the link you provided, and of the other stuff around that link), but in a window in Linux? (which is PM's runtime environment), I don't have a clue how to get started.

I want to create a demo that, hopefully, incorporates a bullet-proof service loop with timers & interactive 'kill' function, but how do I create a runtime environment (a window) that's not inside a browser?

[Moonchild]

I guess you completely misunderstood why I gave you that link...

[markfilipak]

I guess you completely misunderstood why I gave you that link...

Well, I guess I did.