Andrew Gregory

Posts tagged with "opera"

Web Browser Extensions

Thursday, 28. May 2009, 04:06:45

Google have recently blogged about their Chrome browser extensions. Their extensions are basically nothing more than regular web pages, just smaller, and with a bunch of new APIs to obtain the necessary functionality.

It's very similar to what Palm are doing with their new webOS - applications for the new Palm phone are written using HTML, CSS and Javascript.

I've never been much of a supporter of browser extensions. To me, they just add a lot of complexity and trouble to an already incredibly complicated application.

However, back in 2006 I thought that Opera should somehow make their then-new widgets the basis for extending functionality into the browser chrome. I still think Opera should do something like that.

Leveraging existing web development knowledge makes a lot of sense. I'm not convinced that Google's use of separate processes is really necessary. Just lightweight multi-threading so nothing blocks up.

3 comments

Opera Turbo and Internet Filtering

Tuesday, 17. February 2009, 11:22:03

filtering, browser, internet, proxy ...

Opera just keeps on adding all sorts of useful features to their browser. The latest feature is Opera Turbo.

The idea is that Opera runs a bunch of proxy servers that compress the web pages you're surfing. The result is faster surfing, and less traffic. I will especially welcome this when using my relatively expensive wireless broadband connection on my laptop. The slower speed and cost per megabyte will both be relieved a bit by Opera Turbo.

Economics isn't the only reason, though. Here in Australia, our nanny government is trialling Internet filtering. Innocent citizens must be protected from the dark side of the Internet! Whether they want that protection or not. Whether they want their content blocked or not. Whether they want their Internet connection slowed down or not.

It would be very interesting to see if Opera Turbo's proxy technology could bypass the filtering? By appearing to route all your traffic through innocuous proxy servers in Sweden, I imagine it would work quite well. It's a shame my ISP isn't one of the six selected for the pilot.

7 comments

Opera 10 Alpha

Saturday, 6. December 2008, 02:07:29

browsers, wishlist, opera

A new toy to play with! Lots of bells, whistles, and shiny things to poke and prod!

Two-and-a-half years ago (wow, is it that long ago?

) I posted my Opera 10 Wish List. Many things have already been ticked off the lists. Most haven't.

CSS

border-radius: NO
text-shadow: YES
rgba/hsl/hsla: YES
overflow-x/y: YES

75% - Pass

M2 (Opera Mail)

HTML composition: YES
Delete attachments: NO
Newsfeeds in panel: NO
PGP/GPG encryption: NO
Newgroup binary decoding: NO
Improved threading: YES

33% - Fail

Other

Roaming profile: YES (mostly, Opera Link is a very good start)
Download manager: NO
Torrent sub-files: NO
DOM Inspector/JS debugger: YES
SVG as IMG: YES
MathML: YES (it's not fully supported, but it's useful)
XBEL bookmarks: NO
Improved form filling: NO
Default native skin: NO
Default Go button: NO
Drop-down indicators: NO

27% - Fail

A little under one-and-a-half years ago, I followed that up with five more wishes:

Auto updates: YES
Skin/widget/panel/userjs updates: NO
BT UPnP+NAT traversal: NO
Plugin assistance: NO
Drop-down indicators: (duplicate from above)

25% - Fail

Total: 40% - Fail

Not too good.

On balance, however, a couple of the items are big ones that have been asked for by a vast number of people: HTML email composition and automatic updates. Most of the rest of my wishes are smaller items requested by fewer people.

One very welcome addition not among my wishes is the inline spellchecker. Currently, the alpha includes a US English dictionary in the installer. However, I don't see that has being a generally feasible distribution method, unless, of course, Opera decide to return to a vast number of language-specific installers. I'd much rather see Opera distributed without any dictionaries, then have an install-on-demand system, preferably through download URLs to Opera's own servers.

I was thinking about producing a new wishlist, but there are enough NOs listed above that I don't see any point in adding more! Who knows? Opera are still working on version 10, maybe the beta will have some more items ticked off?

15 comments

A CMS to avoid?

Sunday, 28. September 2008, 09:34:30

cms, opera, browser, standards ...

I just had to write about this CMS I just bumped into: Zimplit. It seems to be very, very new. It also has probably the easiest install of any CMS - just copy two files onto your web server.

The reason it's that easy is simple - most of the complexity is handled via off-site JavaScript. The single PHP file is simply the conduit to access your web site files.

Zimplit needs no database - it creates standard HTML pages. Templating consists of you creating your own HTML file. New pages start off as copies of existing pages. It is really very basic. No blog support, no gallery support.

None of that is what prompted me to write this post, though. No, the reason is that I'm sad. It's the Javascript code that's making me sad. You see, Opera is blocked from the WYSIWYG editing features - only IE and Firefox are supported. And I mean Firefox. Seamonkey and any other non-Firefox Gecko browser is also blocked. So is any Webkit-based browser like Safari and Chrome. BTW, an "IE" browser is any browser that claims support for "document.all".

Yep, it's crappy browser sniffing time again.

Anyone who promotes the idea of feature detection instead of browser sniffing would be running around in little circles screaming and pulling their hair out right about now.

There are at least two WYSIWYG editors around that are much better - TinyMCE and FCKeditor. Why the Zimplit guys felt they had to reinvent the wheel and then make such a hash of it I don't know.

Apart from all that, what kills Zimplit for me is the dependency on the off-site JS and images. An international communications glitch would leave me unable to edit my site. Or the company could disappear.

Zimplit has too much going wrong now, and potentially far too much going wrong in the future. One to avoid, I think.

3 comments

Goodbye M2

Tuesday, 8. July 2008, 15:40:54

m2, opera, imap, mail

It's the end of an era. When Opera 7 was released way back at the beginning of 2003, included was the brand-new M2 mail client. The big feature was filters, where you could create multiple views of your inbox. This was a unique feature not seen in other email clients.

I initially found M2 "good enough". Later on Opera added IMAP and RSS newsfeed support. These were all useful. I also really liked how it automatically segregated my various mailing lists.

However, there was a continual stream of glitches. Emails might go missing, only to later return. Some filters might indicate unread messages but not show any. Messages might suddenly appear in folders they shouldn't, eg newfeeds in a mail folder, or newgroup messages mixed in with feeds.

I've also peeked into the actual mail store on my hard drive. I've found countless zero-length files and empty folders. In fact, I have more folders in my mail store than I have files!

The whole system just feels flakey. It did to begin with, but that was OK because it was so new. It's now more than five years old and nothing has changed!

I'm currently in the process of moving my computing life from a desktop PC to a laptop. It's been good to clear old things out, update applications, etc. My current task is clearing out my old emails. My plan was to export messages by account and year into MBOX files. In so doing, I've bumped into a whole slew of new M2 glitches. I'm finding emails appearing in triplicate. Emails appearing in Received but nowhere else (i.e. not associated with any email account). After the upgrade from 9.27 I even acquired a new "ghost" account with no emails in it that only appears in the panel, but doesn't show up in any of the other account configurations.

I'm also getting regular IMAP connection errors that I never got before.

I've tried exporting from Received, but all I get is:

The requested operation could not be completed because one or more of the selected messages did not have a locally downloaded body. Opera will now try to download the missing message bodies.

Nothing happens - Opera doesn't download anything. In fact I don't believe anything that message is telling me! Except for the "not completed" part, that is.

I had no idea Opera would make it so difficult for me to export my emails. I've actually got more than seven years of emails to sort out because I imported all my existing messages when I switched to M2. I expect I'm going to spent many hours, if not days, trying to sort out this colossal mess!

What I'm doing is trying to pick out messages from Received and dragging them into temporary IMAP folders. The problem is Received then shows duplicate messages (the original and the newly dragged message). I can't use account filters to try to categorise messages because then the IMAP folder I want to drag to no longer shows. Once they're in the IMAP folder I export from there to an MBOX file, which I then import into Thunderbird where I can merge them into a single huge MBOX file (much bigger than the limited storage available in my IMAP account).

Once I've collected all my messages into the various MBOX files, I can zip and archive them. To view them, I've found a really nice freebie called Mail Store Home. It can import mail from various sources, including MBOX files, and can sort and search your messages very quickly. I've also found MBOX Viewer, which doesn't need installing and directly reads MBOX files, but it's very primitive - searching doesn't seem to work and there's no provision for sorting. I'm currently investigating a Perl script called mailsort that sounds like it might be able to put my MBOX-es in order.

Since I've switched to IMAP, it's now a trivial exercise to switch between mail clients. My laptop came with MS Office, so my plan now is to switch to MS Outlook. I think I've given M2 plenty of time. I'm now just tired of the never-ending procession of glitches, bugs and missing features. It's time to move on.

14 comments

Working Around the Extension-less Cache

Saturday, 21. June 2008, 03:27:53

extensions, opera, files, management ...

For Opera 9.50, the cache management was changed so that the stored files had no extensions. While I've lost track of the precise reasons (an Opera employee made a statement early on in the beta tests), I have to conclude that it was done for a very good reasons and won't be changed.

Dare I point out that Firefox does the exact same thing? Or that Safari doesn't even make the individual files available AT ALL? Safari puts everything inside a single database file!

For three independent browser developers to arrive at the same solution, indicates to me there is a common problem, and that none of them will be reverting to their previous behavior.

Given that, what can be done to improve your cache-diving expeditions? Opera makes it really quite simple:

Go to Tools -> Advanced -> Cache (shortcut: opera:cache ).
Open the Links panel.
Optionally expand the panel to the full page.
Use the Quick Find field to search for file extensions, eg ".gif".
Use standard list selection techniques (Shift/Ctrl+click for multiple selections).
Right-click and "Save Linked Content As..." or "Save to Download Folder" (your Download Folder is specified under Tools -> Preferences -> Advanced -> Downloads).

What would also be nice, and doesn't seem like a lot of work on Opera's part, would be to enhance the cache display page a bit. Two new columns to show the MIME type and download date/time would be very useful. Furthermore, since it's web-based, and that there are many drop-in solutions for sortable tables on the web, sorting the table by clicking the headings sounds like an almost trivial enhancement.

7 comments

Poor Javascript Coding Quality

Wednesday, 18. June 2008, 16:31:09

web, javascript, compatibility, opera

What is it with Javascript programmers these days? Doesn't anybody know how to program?

I was investigating why tinyMCE 2 (.1.3) is failing in Opera in some circumstances, and what did I find?

Exhibit 1:

if (tos.getEditorTemplate) editorTemplate = tos.getEditorTemplate(this.settings, this.editorId);
deltaWidth = editorTemplate.delta_width ? editorTemplate.delta_width: 0;

The if statement is there for a reason - to initialize editorTemplate to something useful - but what happens if the statement is false? editorTemplate does not get initialized. Look at the following statement - the potentially uninitialized editorTemplate is used! That would generate an error in any browser.

Exhibit 2:

getRng: function() {
  var s = this.getSel();
  if (s == null) return null;
  if (tinyMCE.isRealIE) return s.createRange();
  if (tinyMCE.isSafari && !s.getRangeAt) return '' + window.getSelection();
  if (s.rangeCount > 0) return s.getRangeAt(0);
  return null
},
isCollapsed: function() {
  var r = this.getRng();
  if (r.item) return false;
  return r.boundingWidth == 0 || this.getSel().isCollapsed
},

getRng is obviously capable of returning null. The very next function, isCollapsed, calls it and immediately uses the returned value without checking for null. That will generate an error in any browser.

It doesn't matter how other browsers somehow manage to avoid these obvious bugs - this is just plain crappy coding.

The worst thing is, this is typical of the sort of code that makes the web go. It's a wonder it works at all.

No comments

The Myth of the Robustness Principle

Tuesday, 27. May 2008, 16:06:06

opera, principle, compatibility, robustness ...

... As It Applies To The Web

The Robustness Principle (AKA Postel's Law) was conceived during the writing of the TCP Internet communications protocol, back in 1981. It is often quoted as:

Be conservative in what you send, liberal in what you accept.

Sometimes it is quoted on the Opera user support forums by people frustrated with Opera's seeming inability to handle web sites as well as Internet Explorer or Firefox. The reasons behind all the web compatibility problems are many and varied, and beyond the scope of this post. The purpose of this post is to show that the application of the Robustness Principle is at least partly responsible for some of the so-called Opera compatility problems.

Application of the Principle

When it comes to web browsers, it's typically the second part of the Principle that's stressed, never the first. The truth is, for robust "it just works" functionality, both parts are equally important.

It is vitally important that when faced with some hiccup in the data, browsers do not fall over. Hence, "be liberal in what you accept". It is just as important when sending data, to make sure that it conforms to all the published rules. Any communication involves at least two parties, and in order to be successful, the language used must be the same. If you're not certain exactly how your language may be interpreted by the receiver, you should make sure what you say is as simple and correct as possible. Hence, "be conservative in what you send".

Browser developers have almost turned themselves inside-out doing the "be liberal in what you accept" part. Web developers have virtually ignored the "be conservative in what you send" part.

What does "being conservative" mean for a web developer? At the very least it means the code should conform to published standards, namely the HTML/XHTML, CSS and ECMAScript standards from the W3C and ECMA organisations respectively. That's the only way to ensure that everybody (browsers and developers) are speaking the same language.

Where the specifications are clear, web developers should follow the spec. Where the specifications are unclear, or where they say things like "the results are implementation dependent", then web developers must expect different browsers to do different things and code accordingly (the most robust thing to do would be to avoid unclear functionality completely).

Beyond that, it also means web developers should limit themselves to features widely supported by most browsers. As an example, for nearly a decade HTML 4.01 has specified that you can align table cell contents on a character - for instance, "." to align on decimal points. Very handy for tables of numbers, yet I don't know of a single browser that supports that. (In the defence of browsers, support for that feature is not required.)

If you were to sample sites on the web at random, and test them to see if they conformed to published standards, you'd find probably more than 99% would fail. In essence, that means that web developers have failed to meet their half of the Robustness Principle.

However, even simply following the published rules is not enough. The fundamental problem with the Robustness Principle is that the rules change. Things that were incorrect and therefore ignored according to the Principle, can become correct and require specific behavior as they are implemented. As browsers implement new functionality their behavior naturally changes from earlier browsers that ignored unimplemented features. This is where some "incompatibilities" emerge.

WebForms2

WebForms2 is an extensive addition to the HTML specification. It adds significant functionality to the form controls provided by web browsers, including date (calendar) pickers and field format validation, among many others.

This new functionality has naturally required new HTML parameters (attributes) to be defined in order to request the new functionality. The problem is that many web sites were already using the same parameters for their own use!

The thing is, before WebForms2, the use of such parameters was illegal if you followed the HTML standard. Technically speaking, web sites should not have been using such parameters at all, but following the guide of the Robustness Principle, browsers silently accepted the illegal code.

Then a year or so back, Opera became the first browser to implement WebForms2. Web sites broke, because the illegal attributes they had been using suddenly took on new meaning and different functionality under WebForms2.

For example, this is the reason Opera cannot download printer drivers from the Epson Australia web site. One of the pages in the download process uses a WebForms2 parameter in such a way as to break the Epson Australia server scripts, which results in a never-ending loop of download questions, and Opera never getting to the actual download.

addEventListener

This is how standards-compliant browsers such as Opera, Firefox and Safari allow events to be used on web pages. This function takes three parameters: the type of event to be listened for, the function listening for the event (handling it), and a flag indicating if it is a "capturing" listener or not. Don't worry about what "capturing" means. The truth is, I don't really know the specifics! The specifics aren't important, anyway.

What's important is that up until a few months ago not one browser supported the "capturing" mode - the only mode they supported was the "non-capturing" mode. Following the Robustness Principle, if a web developer happened to request the "capturing" mode, the browsers all helpfully ignored that request and selected the "non-capturing" mode instead.

The problem is that a few months ago, Opera became the first browser to support the "capturing" mode. Suddenly, a good number of web sites stopped working. This was because they were requesting "capturing" mode event listeners, but were coded to only work correctly in the "non-capturing" mode. Browsers had previously accepted the unsupported "capturing" mode without a murmur, giving web developers no indication anything was wrong.

display:inline-block

This is a bit of CSS that is well-supported by Opera and Safari, poorly supported by Internet Explorer, and not supported at all by Firefox. Nevertheless, I have seen several web sites use it, and always in such a way that Internet Explorer ignored it. The result is that Internet Explorer and Firefox effectively ignored the command (following the Robustness Principle), while Opera and Safari understood and processed it. The result is a corrupted web site display in Opera and Safari, but a perfect looking web site in Internet Explorer and Firefox.

"display:inline-block" isn't the only problem CSS. Threads on the Microsoft TechNet forum have huge extra spaces all over the place. This is because the site uses "white-space:pre-wrap", which is again only supported by Opera and Safari. The forthcoming Firefox 3 adds support for that CSS, so Firefox 3 has worse compatibility with that site compared with Firefox 2.

Being Robust is not Being Compatible

This post should by now have clearly demonstrated that simple acceptance of incorrect code will have significant consequences later on. The pain avoided today is simply deferred until tomorrow.

In many ways, the Robustness Principle is actually creating a web that is less robust! It certainly does nothing to fix compatibility problems - rather it creates them!

The solution to web site compatibility problems cannot be found in the Robustness Principle.

No Clear Solution

There is no easy solution to these sorts of problems. The only real solution is to get web developers to avoid unsupported features and to rigorously stick to published rules for HTML, CSS and JavaScript. However, the first browser to dump the Robustness Principle and refuse to accept broken code would quickly become an outcast and ignored by both web developers and users alike.

Education, while keeping the Robustness Principle is in my opinion one of the better solutions. The best example of this I've seen is the iCab smiley. If all browsers could implement a similar feature it would provide a subtle hint to web developers that all is not right with their code. They might be less likely to produce incorrect code if they knew that their visitors could easily see that their code was incorrect.

Such a feature would not fix all incompatibility problems, but it would be a big step in the right direction.

Everybody - web surfers, web developers, browser developers - we all want a web that "just works". Blind acceptance of incorrect code is not the answer. The solution must lie elsewhere.

3 comments

Opera Contains Spyware?

Friday, 23. May 2008, 15:42:36

censorship, spyware, opera, blinkers

http://linuxtnt.wordpress.com/2008/02/17/opera-browser-contains-spyware/

seems to think so!

I made a couple of comments (with replies from "BKB") comparing and contrasting Opera's display of an uninstall form to Firefox's display of a post-upgrade notice. Neither are requested by the user, and both send identical information, in the form of the usual HTTP headers sent for every web request you make in any browser, back to their respective companies. (Unless, of course, the user decides to fill in Opera's form and submit it - that's entirely up to the user.) IE does something similar on a regular basis too (usually after an update). That's no different either. None of it is spyware.

Sadly, balance seems to be a missing feature on that site, as my comments have since been unceremoniously deleted

I wish I'd kept a screenshot. I'd actually thought about it, knowing how sensitive anti-Opera zealots can be. The best I can do is how it looks right now ( http://files.myopera.com/Andrew%20Gregory/blog/linuxnt20080217.png ). If you're wondering why BKB has suddenly piped up after three months and mentioned Firefox with no prior reference - that would be me.

Please don't bug BKB with any further comments. They aren't wanted and will just be deleted.

I started writing this to express my anger and frustration, and to ensure my thoughts on this matter didn't disappear entirely! As I finish this, I'm just sad.

8 comments

TPG Web Menus

Monday, 19. May 2008, 08:20:08

web, compatibility, opera

There's been some discussion on the Opera forums about Opera and web compatibility, which has prompted me to blog this for future reference...

The navigation menus on the TPG web site are nearly unreadable in Opera, but fine in IE, Firefox, etc. More code Opera just can't handle?

Nope.

http://www.tpg.com.au/res/js/stm31a.js

These are old SoThink menus, long since updated by SoThink, but TPG persists in using them.

Line 1010:

nVER=parseFloat(a.substring(a.indexOf("Opera ")+6,a.length));

The menus are sniffing for "Opera " - note the space. That only appears in the User Agent string when Opera is identifying as Firefox or IE (which works around the problem). For Opera identifying as itself, the space isn't there, which results in the sniffing failing and the script determining that Opera is version 0! Which is too old for the script to handle.

The fix is trivial - delete the space:

nVER=parseFloat(a.substring(a.indexOf("Opera")+6,a.length));

I emailed the TPG web master many, many months ago (probably a year or two, now), giving them the exact file name, line number and change to make. Could they find the time to delete a single character? I guess not.

3 comments

1 2 3 4 Next »

Showing posts 1 - 10 of 37.