[haiku-bugs] Re: [Haiku] #7106: WebPositive: Implement haiku error messages

  • From: "Haiku" <trac@xxxxxxxxxxxx>
  • To: undisclosed-recipients: ;
  • Date: Thu, 02 May 2019 13:44:27 -0000

#7106: WebPositive: Implement haiku error messages
----------------------------------------+----------------------------------
   Reporter:  MichaelPeppers            |      Owner:  leavengood
       Type:  enhancement               |     Status:  assigned
   Priority:  normal                    |  Milestone:  Unscheduled
  Component:  Applications/WebPositive  |    Version:
 Resolution:                            |   Keywords:  haiku error messages
 Blocked By:                            |   Blocking:
Has a Patch:  0                         |   Platform:  All
----------------------------------------+----------------------------------

Comment (by sneaky):

 Related: #9334

 I found a stub/fixme for setting page markup and fleshed it out. I'm not
 totally happy with it (I think it needs more parameters) but it does work.
 (Then I found this ticket.)
 It's pretty easy to add internal protocol schemes, too - too easy,
 perhaps.

 Here's how I think it could go, if I understand all the moving pieces
 right:
 - Frame code LoadURL() method gets a special case for a "chrome:"
 protocol. We don't have to expose it to Web+ itself because it's just for
 error messages and the likes.
 - chrome: url is handled by looking up the filename and then injecting the
 content into the page with Frame's method SetPageSource() (maybe with url,
 content-type, charset params added)
 - path lookup for chrome protocol maps to resources "import"ed via rdef
 - the UA itself (ie Web+) in src tree has a "resources" folder where it
 keeps the stuff that'll be imported

 I assume you can load from the app's rc-ed stuff from in the lib, since
 you're looking through a BFile thing?

 The benefits of having real files to edit and the custom protocol would
 be:
 - any web guy with any text editor could improve them
 - shared assets (icons, stylesheets, scripts?) between pages
 - maybe add custom objects/APIs later for JS, like viewing certificates
 - relative paths so you could do most of the design without recompiling

 The benefits of packing them as resources would be:
 - nobody can easily prank you by messing with your error pages
 - fewer inodes

 **Theoretically is it safe to look for resources if they might not be
 present?**
 Like maybe res.LoadResource() just gives you a dead pointer, you detect
 that, and fall back on a BAlert?


 - [https://www.haiku-os.org/documents/dev/compile_them_resources/ Making
 and loading resources]
 - [https://github.com/haiku/haiku/blob/master/src/bin/rc/docs/rc.html More
 on making resources]
 - [http://kb.mozillazine.org/Chrome_URLs List of Moz chrome URLs, related]
 - [https://developer.mozilla.org/en-
 US/docs/Mozilla/Tech/XUL/Tutorial/The_Chrome_URL More about how Moz guys
 do it]

-- 
Ticket URL: <https://dev.haiku-os.org/ticket/7106#comment:15>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.

Other related posts: