search

abhidas17695 / dweb-ext

0 stars 0 forks source link

Domain hack #23

Closed mitra42 closed 6 years ago

mitra42 commented 6 years ago

Rather than passing href back as a property - whick seems like a real hack.

Lets figure out what the semantics of the call from bootloader.js to Domain needs to be and I'll add them into dweb-objects Domain now so that we no longer have to patch the code.

abhidas17695 commented 6 years ago

Do you mean we load the new URL in Domain.js instead of in bootloader.js ?

mitra42 commented 6 years ago

This hack appears to be causing multiple issues. Including #25, #22.

The problem appears to be the simplistic assigning to Domain.href in p_boot , For example I think #22 is caused by a failure to resolve, and then using the previously assigned Domain.href because your code is ignoring the errors returned.

I think the only reason for this hack is because you want to call: chrome.tabs.update(id,{url:url}, function(){}); instead of window.open(url.href, opentarget);. The purpose of p_boot is to carefully handle all the possible knowledge in a Leaf record and decide what to do, or if its an error. So I would suggest. a) Add an argument to each of the calls needed Domain.p_resolveAndBoot ; Leaf.p_boot that says openChrome and defaults to false.
b) in p_boot, if openChrome is true, then it can use your chrome.tabs call. c) handle errors correctly in bootloader.js, by trying to load the original url. Make sure to console log both the error, and that you are redirecting to origianl URL, so we can see it happened.

mitra42 commented 6 years ago

This was fixed in the commit at #26