docs: several pages can be open at once now

The one-page limit came from obscura #756, which upstream fixed in #824.
tests/pages.cfm keeps three live pages, closes them in turn, and runs a
second browser alongside the first.

Author: alexskinner

README.md

@@ -347,20 +347,18 @@ allowed`, which is the guard doing its job rather than a bug.
 
 ## Notes and limits
 
-- **Use one page at a time.** This is a correctness limit, not a speed one: in
-  the underlying engine, dropping a page while a second one is alive aborts the
-  process with a V8 fatal (`heap->isolate() == Isolate::TryGetCurrent()`), because
-  each page owns its own isolate and the realm is destroyed without entering it.
-  One page is completely stable; two is not. Reported upstream as
-  [#756](https://github.com/h4ckf0r0day/obscura/issues/756). Until it is fixed,
-  treat this as suited to tests, reports and sequential scraping — not to a pool
-  of concurrent pages.
-- All browser work also runs on one service thread, so concurrent requests queue
-  behind each other. That part is only a throughput limit, and the design is not
-  forced: pages are pinned to a thread because an isolate cannot move between
-  threads, but a pool of service threads with each browser pinned to one would
-  work. It is not worth building until the isolate lifecycle above is fixed —
-  more live isolates is precisely what triggers the abort.
+- **Several pages can be open at once.** Older builds aborted the process with a
+  V8 fatal (`heap->isolate() == Isolate::TryGetCurrent()`) when a page was dropped
+  while another was alive
+  ([#756](https://github.com/h4ckf0r0day/obscura/issues/756)). Upstream fixed
+  that in [#824](https://github.com/h4ckf0r0day/obscura/pull/824), and with
+  obscura v0.2.5 three live pages, closed in any order, and two browsers side
+  by side all run cleanly.
+- All browser work runs on one service thread, so concurrent requests queue
+  behind each other. That is a throughput limit, not a correctness one, and the
+  design is not forced: pages are pinned to a thread because an isolate cannot
+  move between threads, but a pool of service threads with each browser pinned
+  to one would work.
 - Every call has a deadline. A wedged page raises a catchable CFML error rather
   than hanging the request.
 - A page handle is `Send`, so it is safe to keep in `application` scope and to

tests/pages.cfm

@@ -0,0 +1,32 @@
+<cfscript>
+// Several live pages at once. Before obscura #824 (issue #756), dropping a page
+// while another was alive aborted the whole process with a V8 fatal, so this
+// file either prints its summary or does not finish at all.
+here = "file://#getDirectoryFromPath( getCurrentTemplatePath() )#";
+fails = 0;
+function check( label, got, want ) {
+  if ( got == want ) { writeOutput( "  ok    " & label & chr(10) ); }
+  else { writeOutput( "  FAIL  " & label & " -> got [" & got & "], want [" & want & "]" & chr(10) ); fails++; }
+}
+
+b = Browser();
+for ( round = 1; round <= 3; round++ ) {
+  first  = b.newPage().goto( here & "two.html" );
+  second = b.newPage().goto( here & "hist.html" );
+  third  = b.newPage().goto( here & "app.html" );
+  first.close();
+  check( "round #round#: pages outlive a closed sibling", second.title() & "/" & third.title(), "one/app" );
+  third.close();
+  check( "round #round#: and the last one still works", second.title(), "one" );
+  second.close();
+}
+
+other = Browser();
+mine   = b.newPage().goto( here & "two.html" );
+theirs = other.newPage().goto( here & "two.html" );
+mine.close();
+check( "a page in a second browser outlives one in the first", theirs.title(), "two" );
+theirs.close();
+
+writeOutput( fails ? "SOME FAILED" & chr(10) : "ALL PAGES OK" & chr(10) );
+</cfscript>