Pixelastic

I had a hard time firguring out while my openId login method does not work correctly with Opera.

I either ended up on the redirect page forever, or did not get redirected back to my website after Google check, or finally even get blackholed back on my own site.

I only occured with Opera.

I've read on various places that the security settings of Opera are made to prevent an automatic redirect to a website to be able to write cookie. This is a fair defense, but it does break the whole openId concept. Or at least my implementation.

Some sites manages to get it to work, even on Opera (stackoverflow for example).

I'll hide the openId login method for my Opera users until this is fixed or I find a solution.

The form inputs of this site all have a border-radius and a background-color. Unfortunatly, the latest Opera version just don't like that (9.5 works like a charm).

When you apply the following rules to an input element, Opera will discard your background color and render it as transparent instead.

input {
    border-radius:5px;
    border:none;
    background:#375a5e;
}

All three rules causes the bug. Remove one of them and the bug disappear.

Solution

At first I thought that I could just as well remove the border-radius rule and I won't have any more bugs. But a slightly decreased user experience for my Opera readers.

Then I'll try to come up with a better solution. One can add a background-image instead of a background-color. Odd enough, this won't trigger the bug.

But I wanted to avoid that, that's one more useless request to the server and it's far more easier to change a color code in a css file that to edit an image file.

The solution I choose was to not set a border:none; but to simulate it by adding invisible border. That would add 1px around the input element, so we'll limit it by only adding the border on one of the sides. Adding it on the right side seemed to be the more convenient method.

So here's my updated code :

input {
	border-radius:5px;
	border:none;
	border-right:1px solid rgba(0,0,0,0);
	background:#375a5e;
}

The HTML blockquote element can accept a cite attribute that is supposed to hold the value of the source URI of the quote.

Browsers behave differently when getting this attribute in javascript. Opera and Firefox automatically treat it as a URL, prepending the current domain host if none is defined and encoding special characters.

Safari and Chrome on the other end just return the value as it is present in the HTML.

If you try the following code in Opera 10.51, you'll have some weird rendering bug :

<style>
	.test:after {
		content:"This should be on red background";
		background:red;
	}
 </style>
 Text input : <input type="text" value="I'm unstyled" class="test" />

The generated content is added to the page, but the background color isn't rendered. Worse, the input lose all styling, it does not have a background color nor borders anymore.

The same effect also apply to every input (radio, checkbox and password).

On a select tag, the generated content correctly have it's background color, but still lose all styling.

On a textarea, the styling is gone too, and the background color is here. Well, sort of, it is actually cropped after a while and the end of the text is on transparent background.

I sent a bug report to Opera about that.

One thing that bugs me everytime I use Opera are the weird keyboard shortcuts. You open link in a new tab by using the middle mouse button (classic) or Shift+click (less classic, we are accustomed to use the Ctrl+Click, Shift+Click being used to open in a new window).

Today it was bugging me one too many times, so I decided to use the power of AutoHotKey to help fix this.

Here is the little snippet I added to my default AutoHotKey script :

;        Open page in new tab in Opera using Ctrl + Click
#ifWinActive, ahk_class OpWindow
^LButton::Send +{LButton}
#IfWinActive

It basically catch every Shift+Click in Opera and return a Ctrl+Click instead, allowing me to finally open tabs the way I'm used to.