For the popup provide a full HTML page server-side for all extensions
Closed this issue · 32 comments
We're working on a design and guidelines for the popup (#1) so I thought it would be reasonable to actually provide this page on a server for all extensions to use. There's a request every time the popup is opened anyway.
It would actually make sense to render the page on the server but for now it would also be sufficient to just move the whole HTML + JavaScript we have now in the extensions just downloaded from the server when the popup is opened.
sure, good idea. that's also what render.js does for the website, it's the
old index.html code ported to node.
On Mon, Oct 1, 2012 at 7:58 PM, xMartin notifications@github.com wrote:
It would actually make sense to render the page on the server but for now
it would also be sufficient to just move the whole HTML + JavaScript we
have now in the extensions just downloaded from the server when the popup
is opened.—
Reply to this email directly or view it on GitHubhttps://github.com/didnotread/browser-extensions/issues/2#issuecomment-9042991.
What do the others think? @AbdullahDiaa @shybyte @e-user
@michielbdejong Could you implement that?
Just to get this straight: In this proposed solution, loading the popup for a service means just to render a website in a chromeless browser window?
Kind of. Hm, don't know about IE. All the other browsers have popups that visually belong to buttons or address bar icons as part of the extension API. And all of them look basically the same. So my idea was to also use the same code and loading approach here. It may be completely different for IE. Maybe you can provide screenshots of how your extension will look like?
IE doesn't have popups. Nor additional address bar icons. My implementation works totally different, I'm using a user-level service WPF application that runs in tray icon mode by default. Loading websites in Internet Explorer communicates the new domain name one-way each time a new website is loaded, so the IE process isn't blocked or anything, and debugging IE add-ins is hellishly difficult, so you don't want any more code to run in there than absolutely necessary.
WPF, is the new-school approach to GUI Windows applications and supersedes Windows Forms applications. It works very similar to HTML, as a matter of fact, but allows for using the visual styles of a user's Windows theme. The downside is that I have to maintain a completely incompatible parallel implementation of loading, assembling and rendering the service data, which is what's taking me so long.
If you can't run the code for yourself, here are some expressions of what the implementation currently looks like (Windows 8, IE 10):
http://cloud.akahl.schokokeks.org/public.php?service=files&token=6bc0093fcabb2b94d896a3189122ccabbdca46e8&file=/tos-dr_addon.png
http://cloud.akahl.schokokeks.org/public.php?service=files&token=49f61857d194f94b496ecb25c199a985f6bb6207&file=/tos-dr_ie.png
http://cloud.akahl.schokokeks.org/public.php?service=files&token=96388fa4ea40a820af70478335a9c54ca203d694&file=/tos-dr_tray.png
That would also be useful for a browser bookmarklet. Someone was working on that, but I forgot his nickname…
Ha, I found it: http://jill-jenn.net/tos-dr/sites/twitpic#twitpic
@e-user So what are your plans to display the detailed ratings? In the other browsers this popup is just displaying a plain old HTML page.
Great that you work on that for IE btw!
@hugoroy Ok, great, we should take that into account, too. It's also a kind of extension so maybe you can invite that person to take part here?
Yes but I don't find his contact details any more :-/ @michielbdejong you got an email from him where he asked you for advice… can you find it? I will search my inbox more thoroughly later.
@xMartin My original plans were to do the rendering and data aggregation myself, using WPF (XAML), but resembling the original Chromium and Firefox popup as closely as possible. Of course, using server-side created HTML pages would simplify the job immensely, all I'd have to do would be to have a web widget render the pages, which means I'd be 99% done already.
That being said, has it been decided we want to and actually can use pre-rendered HTML popups? In that case, I would stop my current effort as it would turn out to be a waste of time.
Great I can help you guys in the first place :) It's a little bit ironic that I'm doing the proprietary platform integration, as a strict Free Software guy.. that's fate I guess.
The bookmarklet could also just then display the server-side HTML in an extra div. It will essentially look like the browser extension popup, except that it overlays only the site and not the browser chrome (which is why I prefer proper browser extensions for this type of thing, because of credibility). But it works for when you can’t install extensions.
Is there any progress here? Cause if yes, there's no point for me in continuing to replicate the popup in WPF.
@e-user If you can use some kind of web view or HTML view you can also use what is used in the other browser extensions right now. Check https://github.com/didnotread/didnotread-chrome/blob/master/app/popup.html. Would that work for you? We still want to improve it and make it simpler (that's what this issue is about).
Hey @xMartin, I was actually referring to server-rendered pages. Again, I can't re-use any of the existing implementation; I could maybe re-use the HTML/CSS view if I rewrite half of the application. It would be much easier however if each implementation didn't need to assemble and render the data separately.
@e-user Please specify the restrictions you have. No JavaScript? Or is it only about the hosting because you can't load local resources?
@xMartin So far, I'm not using any line of code from the other implementations at all. Now that I think about it, it might just be possible to do a web-based implementation inside the Windows application I've created, but I can't promise that, yet. Please check my other comment above about the current implementation works.
@e-user Yes, I'm just wondering what the difference is between a pre-rendered server-side HTML document including CSS, images and maybe some JavaScript and rendering a local HTML document using Ajax with remote data. So if you can define whatever restrictions you have here we can set it up accordingly. The only thing browser extension-specific is the way to get the URL of the active browser window.
My implementation has to run as a native application in order to work, at all. I don't even know whether I can just use the existing HTML/CSS/JS implementation as an embedded web widget running the code locally or something, but I can try. I suspect debugging will be really really difficult that way, since it will be something like Window -> Web Widget -> JS code, while the actual application runs and "sees" the window and web widget itself, only.
@e-user I've hacked something together that works for me in IE 10. It is slow but maybe it helps you making some progress. We should resolve #3 soon.
https://github.com/didnotread/browser-extensions/tree/gh-pages/popup
@xMartin, I think I'm still totally misunderstood: So far, the IE "popup" doesn't render as a web page and I don't know whether it's simple to make that possible: Even if I render a web widget, since the page is local I have to somehow pass down what service data to load from managed (.NET) to JavaScript VM (in IE) code.
@e-user I know it doesn't do it so far. I thought you were optimistic about it being possible and you wanted a page on a server. So what is it that you want if not a page like I provided? I don't get what you're requesting is in this thread.
@xMartin at home I only have Win7 with IE9, where your hack doesn't work - I also can't figure out how to have IE tell me about scripting errors, not even with the built-in developer console. If you can make it work in IE9, I can probably use it, as you are simply passing the URL as part of the request string.
I know it's not working in IE 9. Will have a look at it. IE 9 has actually quite usable debugging tools.
Am 18.10.2012 um 19:17 schrieb Alexander Kahl notifications@github.com:
@xMartin at home I only have Win7 with IE9, where your hack doesn't work - I also can't figure out how to have IE tell me about scripting errors, not even with the built-in developer console. If you can make it work in IE9, I can probably use it, as you are simply passing the URL as part of the request string.
—
Reply to this email directly or view it on GitHub.
Working in IE9 now.
I got my application to use an IE control now. Unfortunately, it renders webpages in IE7 mode by default (which results in http://cloud.akahl.schokokeks.org/public.php?service=files&file=/akahl/files/clientsync/wpf-ie-script-error.png), but it's possible to set the compatibility as described here:
http://stackoverflow.com/questions/4612255/regarding-ie9-webbrowser-control
@xMartin, would you please add the necessary <meta http-equiv="X-UA-Compatible" content="IE=9" >? Thanks!
While that change makes the pages render, now, two new issues have been uncovered:
- On pages with data points, I get multiple JS errors that
innerHTMLwas null or undefined, but it loads fine otherwise; doesn't happen in "normal" IE - I can't get the widget to change the URL when only the anchor (
#) has changed and reload at the same time (i.e. more than one of these things per event). In other words, can you please make it work using either path info or get parameters instead of anchor name?
Now, this looks much better, thank you! Unfortunately, all but one data points per service are now missing in both normal IE9 and the control, but the innerHTML error is gone instead.
Furthermore, I suggest overriding oncontextmenu with something that returns false, and prevent other events such as history back. One could still "abuse" the control as a normal web browser window, otherwise.
In order to prevent privacy exposure through the get parameter appearing in github locks, I'm forming a "neutral" URL from the matching service's base host, FWIW.
@e-user To me the content of the page in IE9 looks the same as in Firefox.
From (five minutes of) reading through the comments, looks like this was solved. As I understand, all browser extensions are now using the common html code from this repo. If I find otherwise while looking at any of the extensions, I'll open a new ticket for that, because obviously it's good to have just one html popup, and minimal duplicated code in the five actual extensions.