Sitepatching updates

tweaking the broken code until it works, one site at a time

Workarounds for Google Calendar, Twitter focus

Ola is on vacation so it's my turn to keep you updated and fully sitepatched. Fun to blog here again, and I have some high-profile problems fixed this week. bigsmile

Changed patches
PATCH-260 Westjet browser sniffing warns against Opera
This site used to have a really broken constantly re-loading "warning page" for "unsupported" browsers. They've fixed that, so we removed this patch in March - but as the site is still sniffing and warning against using Opera, we might as well keep the patch active. Now restored.

Removed patches
DSK-187263 GMail deletes messages on End key presses (core fix)

Added patches
PATCH-251 Newsday.com: delayed document.write overwrites the page content
A number of sites call document.write() by mistake after the page is finished loading, overwriting it with some small ad or invisible graphics for user tracking. Here is one offender. There are two reasons Opera encounters this: the most important is browser sniffing, but I also believe an IE bug or feature makes IE ignore document.write() under some circumstances. If a page calls document.write() when IE is in this quirky mode, they will overwrite the page in a browser with a less buggy document.write() support.

Opera Mini found and patched this first, since the problem also applies to Desktop we now push the patch here too.

PATCH-262 Layout regression squishes event detail edit screen on Google Calendar
This makes Google Calendar usable again, saving the Desktop guys from feeling more pain because they took in a last-minute untested fix they should have left alone.. angel Just don't do it again, OK?

PATCH-261 Hide broken implementation of showModalDialog to make object detection reliable
window.showModalDialog() is an IE invention which is sneaking into the HTML5 standard in spite of my silent dislike of it. Thanks to David Bloom at Google we noticed that we've accidentally shipped a half-baked and dysfunctional implementation of it. This breaks object detection since window.showModalDialog exists and is a function - to make object detection work for developers who want to write replacement functions we ship a small patch that deletes the reference to the broken implementation.

PATCH-263 Twitter tries to focus a display:none TEXTAREA, removing focus from main status update box
Hi Rafael, sorry it's taken me a while since you reported it but finally the patch is out. The status box on Twitter should no longer loose focus when the page is finished loading smile There's also a core bug on making Opera ignore attempts at calling focus() on an element with display:none.


PATCH-264 @mentions feature requires correct cancellation of enter keys
Here's one that hopefully will make Facebook happily enable @mentions for Opera users. They pointed out that if enabled, confirming a @mentions entry with the enter key would also insert a line break. The reason is that calling event.preventDefault() from keydown doesn't stop the default action of a key in Opera - you need to prevent the keypress event's default action. (This is a very silly incompatibility which we'll fix in an upcoming key event rewrite).

So, calling Facebook: we've worked around the bug so you don't have to, do you have a moment to remove the Opera detection from this statement? As you can see from the screenshot it works pretty well now..

this.suppressMentions=(ua.opera()||ua.firefox()<3||ua.safariPreWebkit()||ua.iphone());


Thanks in advance smile

Removing more from 10.6 fileSplit file for 10.70 and eBay, TVGuide patches

Comments

Galileo Thursday, July 8, 2010 1:55:57 PM

up
P.S: If you happen to have some time to check these 2 scripts, http://userscripts.org/scripts/show/8861 and http://userscripts.org/scripts/show/46560. They cause the chat scroll problem but the creator of facebook ads says he doesn't touch the chat box. I have made comments for both scripts http://userscripts.org/topics/54951 & http://userscripts.org/topics/55184 (t125 username, Galileo it taken sad )

Charles SchlossChas4 Thursday, July 8, 2010 2:26:48 PM

up

Daniel HendrycksDanielHendrycks Thursday, July 8, 2010 4:12:10 PM

Originally posted by sitepatching:

this.suppressMentions=(ua.opera()||ua.firefox()<3||ua.safariPreWebkit()||ua.iphone());


Did you show Facebook this with their contact tools (e.g. their help forum)?

setsutekh Thursday, July 8, 2010 4:36:49 PM

Can you somehow exclude browserjs on acting on thepiratebay.org, because right now it gives:
Opera has modified the JavaScript on thepiratebay.org (eBay). See browser.js for details
in the error console, one line for every PirateBay page. I don't know if it actually alters anything on the site, tho, but it would be nice to at least reduce cluttering of the Error Console a bit, if nothing else.

d4rkn1ght Thursday, July 8, 2010 6:20:34 PM

up

Rafael Luikrafaelluik Thursday, July 8, 2010 9:06:42 PM

yes
Twitter is working very fine now.
Now they just have to fix the border-radius issue I reported them. smile

It's great to see Facebook @mentions case is moving forward.

Many thanks for this update!!! happy

ouzowtfouzoWTF Friday, July 9, 2010 1:17:33 AM

Since 10.6x (10.54 is working fine!) I have problems with some JS code (seems, I'm not to firm in that) throwing exceptions (DSK-302997). What I understood is that the JS resizes the height of an iframe. Should I attach the JS errors from the error console to the bug or is somebody of opera getting an account on studivz.net/meinvz.net to look at it?

So far I have two bugs with Opera 10.6 preventing me from using 10.6 exclusively and not having to use 10.54 sometimes sad

MyOpera team, please fix this!fearphage Friday, July 9, 2010 1:35:34 AM

what's the lowest version of opera that will get the facebook fix?

Hallvord R. M. Steenhallvors Friday, July 9, 2010 9:13:00 AM

Originally posted by DanielHendrycks:

Did you show Facebook this with their contact tools



The OTW/Developer relations team at Opera is discussing this with Facebook developers.

Originally posted by sutekh:

Can you somehow exclude browserjs on acting on thepiratebay.org



Hm.. That is actually a really bogus message, it's from the eBay patch but the code that runs does not actually make any modifications. I'll look into it.

Originally posted by ouzoWTF:

DSK-302997


I'll look at that - if you set up a test account and PM me the login I promise to get to it even faster wink

Originally posted by fearphage:

what's the lowest version of opera that will get the facebook fix?



For now 10.50 but that's a bit arbitrary, if someone sticks to 10.10 we can probably ship it in a file for this version too smile

ouzowtfouzoWTF Friday, July 9, 2010 9:57:45 AM

Originally posted by hallvors:

I'll look at that - if you set up a test account and PM me the login I promise to get to it even faster


Done smile

Cutting Spoonhellspork Friday, July 9, 2010 5:05:17 PM

Originally posted by sutekh:

Can you somehow exclude browserjs on acting on thepiratebay.org


Hey, you're right! That's hilarious...and troubling?

If Opera is applying patches for short URLs to longer URLs that contain the shorter string, this could explain why some browserjs and userjs seem to cause trouble on unrelated websites. I'll be keeping my console open for a while, see if any sites I visit have a similar symptom.

Unregistered user Saturday, July 10, 2010 10:15:43 AM

Anonim writes: Hallvors, the way that you use to find if site is to be patched or not is SERIOUSLY flawed. JS regexp/indexOf based on domain.. It might be a good stopgap sollution few years ago, but now you need to seriously fix it. Javascript isnt perfect tool, and should not be used, if core methods might be used (same for your developer tools, unfortunatelly). I've seen examples of similar erros like this pirat[ebay] error. You need to use browser.js, it is a fact, but this framework needs to be MUCH more robust that now.

Hallvord R. M. Steenhallvors Sunday, July 11, 2010 11:15:14 PM

Originally posted by anonymous:

the way that you use to find if site is to be patched or not is SERIOUSLY flawed. JS regexp/indexOf based on domain..



I know indexOf() on domain name is flawed. It is a compromise between correctness, performance and security (remember that all code we want to run needs to be signed, so if we split the file into smaller per-domain pieces plus one generic file we'd potentially have a lot more signature checking to do).

Plus a nod to readability - it's easy to see what's going on.

indexOf() on domain name is imprecise - but it is fast, and that matters when we run it hundreds of times at the start of loading every page and every IFRAME with scripting inside that page. This code is going to run quite a lot during your browsing session.. In my experience indexOf() has been correct enough for this purpose in so far I don't remember a single case where a patch running on the wrong site due to a sloppy indexOf() check has actually broken that site..

I'm not wedded to the current approach, but we have made a few attempts at improving it and not found a really elegant replacement. We will probably keep trying new ideas from time to time, and suggestions are welcome (especially from people who know C since I'm obviously coming from the JavaScript / User JS side of things - "when all you have is a hammer" etc.).

Unregistered user Monday, July 12, 2010 4:18:38 PM

Anonymous writes: This is bad. IndexOf() is a ducttape-like solution, but if you say it works fast I'll not opose. But that also means, that Opera' core does not expose any API calls that could help you with. No matter how much you like Javascript, it is, and always will be a slow (very slow compared to C) solution. Using C-based APIs one can make it much more robust and still waaaay faster than Javascript ones. The same applies to Dragonfly (stupid) idea to base its entire logic on Javascript. There are things that can and should be done inside Core (like profiling, net traceing, cookies etc) but instead they are done with plain JS calls. So how one can measure time required to do var d = new Date()?

Cutting Spoonhellspork Monday, July 12, 2010 5:15:02 PM

One may refer to this as a matter of compromise...? There may be some performance penalties associated with Opera's implementation but I'd rather not get into hybrid XUL-script or some other nightmarish solution.

On the core side, new logic patches have made many browser.js fixes unnecessary. One may view browser.js as an intermediate fix pending better core logic. As a user, I feel that this has worked well for me. I also have the recourse of user js for certain offending pages, but I understand that this is not for everyone.

I suppose the real question is whether a simple test of TLD length could be fitted with minimal performance hit. Such as, only if a patch appears to match, snip and check the lengths of the two strings.

Unregistered user Monday, July 12, 2010 6:53:37 PM

Anonymous writes: yes, I agree, that browser.js IS needed, and it IS very effective. There is no denying that. BUT while Opera finally fixes some outstanding incompatibilities, list of such issues is long enough still. That will make browser.js a main feature for years. And size of this file WILL grow. That alone would justify in my eyes at least a SERIOUS internal discussion. And XUL? XUL has nothing to do with this, it is simply a matter of exposing some (much needed) APIs outside Opera core. Debugging tools WILL suck until this is done :/ and browser.js will never reach its full potential. BTW part of this were done already with Magic Variables, that are nothing else than hacks to normal rendering engine.

Hallvord R. M. Steenhallvors Monday, July 12, 2010 7:11:34 PM

It certainly has been discussed internally, and serious proposals to do things differently have been tabled. However, the alternative proposal usually is splitting the file into small per-domain files and moving the domain check into core - much like User JS already has @include comments, I guess. We haven't much considered exposing APIs from core - if I'm understanding your correctly, one of your suggestions would be something like

if(opera.isMainDomainPart('ebay')){ ... }


which is worth considering now when we have a real TLD database..

Rafald.i.z. Monday, July 12, 2010 7:29:26 PM

it is simply a matter of exposing some (much needed) APIs outside Opera core. Debugging tools WILL suck until this is done


That's slightly off-topic but I'm not sure if you know how Opera debugging tools work. They use scope API which is exactly the thing that you are saying it should have. For 90% of things it does, it does them through specially exposed core API's. What you see as a Dragonfly is just a frontend (or UI) for scope. You can write c++ native application that does the same things as Dragonfly if you are brave enough.

Unregistered user Tuesday, July 13, 2010 5:15:55 PM

Anonymous writes: Yes, I'd like to see something like opera.isMainDomainEtc(arg). That way the robust logic (like handling numerous cases like many subdomains on pages like ebay or amazon) can be handled core-side, with blazing C speed. Magic Variables are already in, opera can add some more usefull hacks. And no, I do not know how does dragonfly works, but I tried to read DF source, and was under impression, that most of the logic (UI included) is written in JS.

Cutting Spoonhellspork Tuesday, July 13, 2010 6:26:04 PM

Anon, look at scope source on github. DF sources are written with API calls that use JS-like syntax for consistent readability. Think of this in context to Opera's extra APIs for Unite and for Application Widgets. Opera does occasionally expose new APIs, and mostly in simple script syntax.

Daniel HendrycksDanielHendrycks Tuesday, July 13, 2010 7:08:41 PM

http://kaleidoscope.terion.name/
It does not load at all.

José Batistawyldkat Tuesday, July 13, 2010 7:09:00 PM

Unregistered user Monday, July 19, 2010 10:02:07 AM

Anonim writes: "The same applies to Dragonfly (stupid) idea to base its entire logic on Javascript." - just like Firebug does. But for some reason, you only complain about it in Dragonfly!

Hallvord R. M. Steenhallvors Monday, July 19, 2010 12:18:32 PM

The document.write() problem we're patching on newsday.com might be related to http://www.w3.org/Bugs/Public/show_bug.cgi?id=9767

Cutting Spoonhellspork Monday, July 19, 2010 5:41:04 PM

"Because even when they agree on the words, they can't agree on the grammar." The worst part is that so many of these bugs exist to support Internet Explorer's stupid people tricks.

Hallvord R. M. Steenhallvors Wednesday, July 21, 2010 11:57:37 AM

Originally posted by DanielHendrycks:

http://kaleidoscope.terion.name/


This is now tracked as CORE-31456, described as "overflow:hidden hides background image in a transformed (rotated) element"

Originally posted by wyldkat:

I think you guys should check this:

http://my.opera.com/community/forums/topic.dml?id=568301&t=1279048130&page=1#comment5852782



Interesting. I didn't know we behave differently if classid is set (seems we apply more heuristics to guess what the content is and what plugin should be used if there is no classid?).

Cutting Spoonhellspork Wednesday, July 21, 2010 7:05:38 PM

If I had to guess, there are cases where detection is skipped to improve loading speed?

Ola P. Kleivenolak Thursday, July 22, 2010 3:20:51 PM

It's all covered here: http://my.opera.com/sitepatching/blog/2010/02/25/new-java-support-and-object-parsing (and implicitly in the HTML5 spec) - object with non-empty classid is ignored. We did this to align with Gecko/HTML5 for 10.50. WebKit's handling is somewhat magic and nothing to try to mimic - presumably they will align with HTML5 eventually. Algorithm is quite simple and predictable (unlike our old handling p )

If empty or non-existing the usual object handling kicks in.

As d.i.z points out, Opera gets different code from Gecko/WebKit.

Pierre De Grootepierredegroote Friday, September 3, 2010 7:39:29 AM

Where can I find de script for PATCH-262?

Ola P. Kleivenolak Friday, September 3, 2010 9:21:13 AM

/profile/browser.js - search for "PATCH-262" (check opera:about to find your profile directory)

Hallvord R. M. Steenhallvors Tuesday, September 14, 2010 4:27:29 AM

(Apparently a Google Calendar update may have broken PATCH-262. Apparently yet another Google Calendar update has obsoleted it. If your Google Calendar is currently broken in Opera perhaps Google's latest update hasn't reached you yet - it should shortly.)

flos Saturday, May 14, 2011 3:29:09 AM

Patch 262 problem (or similar) reappeared.
Opera 11.10 Build 2092

Write a comment

New comments have been disabled for this post.