Change container width to more than 32767 with jquery in Opera - javascript

I want to make a mini timeline with jquery and for this timeline to have a width more than 32767 px. When I change it with jquery $(".timelinecontainer").width(32767); in Opera does not change it, but in others browsers it works.
Can you give me advice on getting it to work in Opera ?

I suspect that Opera keeps the window width as a short and thus is not able to handle values larger than 32767. You should probably change your approach anyway and scale the timeline to fit the current window, then give the ability to zoom in on portions of it. I think your interface will look and work better this way. The way you seem to be doing it, the user will have to do a lot of scrolling to view the timeline and won't ever be able to see it in its entirety.

I'm sure I'll get flamed for saying this but--you could just ignore Opera.
If you like how things look in the other browsers (IE,FF,Safari/Chrome), then I'd say you've got 99% of your bases covered.
You may want to file a bug against Opera, of course. (though I guess it could be jquery--it may have a different code path for Opera). If you could make a simple HTML page to reproduce the problem, you'd know. Then, attach it to the bug report.

This is a very old Opera bug which for some reason they can't resolve. Opera is popular only in some regions and mostly this bug is ignored by the developers.
There is no automated solution for this. As a quick solution you can detect web-browser in your script and limit the width for Opera. As an example - scroll this guitar tab to an end in Opera.

I can confirm that this is indeed a bug in the current Opera versions. The good news is that we're working on fixing it (I work for Opera, so I know what's going on there :)), so in the not too distant future your script should start working as you expect.
I'd actually suggest that if the workaround the first answer above suggests is too hard to implement, you should ignore the problem and wait for the Opera upgrade that fixes it.

This is a bug and it has been fixed in the Opera 12 pre-alphas available from http://my.opera.com/desktopteam

This is definitely a bug with Opera.
Coincidentally, I was seeing it for the first time just yesterday. In my situation I have an inner container with width:9999em and an outer container that uses overflow:hidden and scrollLeft() to create a carousel. In Opera the scrollLeft() stops responding at that width.
File a bug with Opera: https://bugs.opera.com/wizard/

Sounds like an Opera bug to me, too.
Why not take a look at Simile's Timeline project (http://simile.mit.edu/timeline/) and see how they've done it?

Related

SVG filter feGaussianBlur in not working properly IE browser

I'm using SVG element of HTML5 and it's working on Firefox, Chrome and safari but it's create problem on IE11 you can see the screenshot I attached.
On IE11 browser you can see the sharp edge upper side of puzzles area on other browsers it's smooth.
you can check the code on below mentioned link:
https://jsfiddle.net/agsyhzc1/2/
Please help me how to resolve this issue.
Thanks in Advance
It is should be supported link, but i had simmilar problem, took me a long time to sort it out kinda, I used https://modernizr.com/ to check if svg property was supported if not I ended up doing a fallback with transparent PNG as overlay. It is hack but it is the only solution i came up with. It is relevant for older IE I think that Edge

Randomly inconsistent height returned by Javascript in Firefox for Android

I am working on a web app, visible here.
On desktops, I don't have any problems. However, in Firefox for Android, $('#station-'+id).height() takes two values, and it seems to be one of the two, at random.
I can't find why I have such inconsistent behavior… It only happens in Firefox for Android (but I only tested desktop browsers and Firefox for Android).
Do you have any idea ?
Thanks !
I had the same problem with screen.height, changing it to screen.innerHeight fixed it. I don't know if this approach is going to work on any element on the page though. Note that you'll have to subtract the padding values if you want to convert the innerHeight to the height.

Chrome Media Query w/ Scrollbars Change

Chrome used to improperly exclude the scroll bar in its media queries. This means that with 1000px of visible space and a 17px scroll bar, other browsers would report 1017px as a width so far as Media Query is concerned, but webkit browsers (such as Chrome and Safari) did not do this.
These browsers could hit a specific size where a scroll bar would appear in one resolution, then change resolutions to another where it would appear, then it would go back to when it didn't... the solution caused an ugly blank space to appear where the scroll bar should, but it did not. It came out looking like a glitch, and the DOM resize events did not fire properly so it was not something you could react to properly in JS.
However, now in Chrome 29, this appears to have changed. Now they are going off of how the specification works and including the scroll bar in their media query calculations... just like Firefox and Internet Explorer (and how the specification says they should have all along). This fixes the bugs, but causes another problem in that the JS to try to detect the Chrome/Safari issue now will have false positives, because it is not a concern with newer versions of Chrome and I assume eventually Opera and Safari as well.
In light of all of this, I cannot find any information anywhere on when this was fixed in either Chrome or Webkit. I hate having to resort to browser version testing in my JS to work around these flaws, but I am just guessing blindly on Chrome 29+ for the moment as a temporary patch and would love an authoritative answer... I have tested in Safari 6.0.5, but the old method is still being used...
Does anybody know in what version of Chrome and/or Webkit this was fixed?
Chrome is no longer using the webkit engine as of Chrome v. 28 it now uses the Blink Rendering Engine. So no need to be detecting this for chrome unless you need it for previous versions.
For more on Blink: Blink Documnetation
For more on the Release: Next Web Article on Webkit/Blink Switch

Rendering bug in Google Chrome at certain window widths

My users and I are running into a rendering glitch in Chrome only (on both Windows and Mac) where an overlaid div that I'm using for on-hover tooltip-style "popouts"(see first image below) does not get rendered properly in certain cases (see second image below). In all other browsers I've tested, it works as expected.
Here's how the hover popouts are supposed to look (and what happens in Firefox, Safari, IE):
Here's what happens in Chrome:
You can see it in action on this site if you look at May 24 using a browser window width of ~ 1200px (significnatly wider or narrower windows do not seem to work). The glitch only affects the popouts in the bottom right of the menu that are popping left, e.g. those on May 24. Hovers using the same exact mechanism higher up in the page work just fine. Glitched popouts are invisible (except for part of the carat), but if you click on the link to lock the popout in place and then hold left click while moving your mouse around as if to "select text" in the area where the popout should be, it will then render partially. Also if I open dev tools and try to select the popout, it will render just fine at that point.
I've been looking at this all day and trying different work arounds with opacity, z-index, etc. and getting nowhere. Does this glitch ring any bells for anyone? Is there a way to force Chrome to render the div, once its been positioned and unhidden? I'm fine with any work-around or hack.
I use a custom (and fairly complicated) jquery plugin for popouts. If it would be helpful to see the non-minified javascript for the plugin, I can post or provide a link to that, but general guidance that leads me to a work around will be sufficient to be accepted as an answer.
Edit: My Browser Build: 26.0.1410.65
(Per my comments)
This does indeed seem to be a bug in Chrome, though without a smaller test case to reproduce it, it could be very hard to track down. You may want to report it to the Chrome team with as much information as possible.
In support of my "it's a bug" assertion:
The hidden/clipped elements become visible when they are selected.
The elements underneath the hidden/clipped elements are not clickable.
This indicates that z-index and height is correct.
It only happens under very specific circumstances; the rest of the items with the same style work fine. The same item may work fine at a slightly bigger/smaller screen width.
Applying a 3D transform fixes it.
The problem goes away when I apply a CSS transform such as scale3d or translate3d. I imagine this is because certain CSS properties cause the browser to switch to GPU acceleration.
In this case, switching to the fast path for rendering seems to alter the drawing sequence enough to fix the problem.
Super hacky but this fixes it for me:
$('.drop-link.food').on('hover',function() {
$('.tool-tip').css('overflow', 'hidden').height();
$('.tool-tip').css('overflow', 'auto');
});
Obviously this isn't a "good" solution, and even remaining hacky you could probably optimize it to only force the redraw on the tooltip it needs to, but hopefully it helps...
Another clue:
$('.drop-link').on('hover',function() {
$(this).siblings('.tool-tip').css('display','block');
});
This won't fix it right away, but it seems like if this is there, once you've hovered on something, it will work the next time you hover on it.
Not sure if this helps with your situation, but over the last couple of days I've started to notice that certain site elements on Facebook and Weight Watchers no longer show up. Specifically it seems to be affecting items that (I believe) to be controlled by or dependent on Javascript. When I call up these sites in Firefox and Safari they work as expected.

Drag and drop lagging

As part of a school project, I have DIVs that I need to be able to move. I have it working, and it works perfectly in Firefox. However, in other browsers, it doesn't really work that well. In IE9, it doesn't work at all. In Safari, it lags, even when only one div is up. In Opera and Chrome, it works fine when there's only one div, but if there are several divs on top of each other, and I try to move one over the others, it lags.
I've been going at it for a while, and I've really run out of ideas as to what could cause it.
As this is for school, we're not allowed to use any libraries (as this would have simplified it quite a bit).
The code for making divs draggable is here: http://pastebin.com/4TGRg1AW
Are you not allowed to use something like jQuery? It takes care of a lot of js browser compatibility issues.

Categories