Me and a few classmates are working on a project where we have to make a webshop.
We are working with Github so everyone has the latest version. Everyone is using Google Chrome, so am I. On my classmate's browsers the webshop works just fine. And on mine there is a giant invisible div that covers the whole page so I can't click on anything.
This is the div I'm taking about:
<div style="position: absolute; z-index: -1; top: 0px; left: 0px; right: 0px; height: 1001px;"></div>
If I use "Inspect Element" this div will be shown almost at the bottom of the html code. (Just above the tag. It also takes his with from the container we use. And on the browsers of my classmates the whole div doesn't excist!
So my question is: Is there anyone that knows how to fix this?
EDIT: In IE it works just fine for me too. Only Google Chrome creates this weird div.
it's because of extension named "smooth scroll" on google chrome, try disabled or remove it
Related
Edit: Pending a reply from someone with a fix, I'm going to assume this is a bug. It looks like it may be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1794432, though the thread on the tracker is sparse, so it's unclear if Mozilla has determined it is a bug. Contradictory to the thread there, it appears that during my testing any embeds cause this problem, and setting layers.force-enabled does not fix it. I'm leaving the question up with a link to the bug tracker in case someone stumbles across this due to encountering the same issue.
I'm working on a site with a sticky navbar using backdrop-filter to blur the background. This works great, but on pages with an embed (iframe, object, etc.), the filter appears to break in Firefox as scrolling approaches the embed. It doesn't appear to be due to stacking contexts (the navbar remains on top), but I'm at a loss as to what is causing it. Before I file a bug report, I wanted to get input and see if this is a problem with my code, and if anyone here knows the solution. I've included a reproduction below -- viewed in chrome, behavior is as expected; viewed in Firefox, however, the filter breaks on elements surrounding the embed. I've confirmed this happens with a pdf embedded in an object tag as well. I've included the code for a minimum repro below, and there's a link to a JSFiddle here: https://jsfiddle.net/gamo2zy3/1/
.navbar {
position: sticky;
top: 0;
left: 0;
width: 100%;
height: 100px;
z-index: 1;
backdrop-filter: grayscale() saturate(180%) brightness(50%) blur(50px);
border-bottom: 1px solid rgb(0, 0, 0);
background-color: rgba(0, 255, 0, 0.1);
}
content-container {
display: block;
width: 500px;
}
div.takespace {
height: 1000px;
}
img {
width: 100%
}
.embedVideo-iframe {
aspect-ratio: 16 / 9;
width: 100%;
height: 100%;
}
<nav class="navbar">TEST TEXT</nav>
<content-container>
<img src="https://w.wiki/64tg" />
<div class="takespace"></div>
<img src="https://w.wiki/64tg" />
<iframe src="https://www.youtube.com/embed/B4Kn3djJMCE?rel=0" class="embedVideo-iframe"></iframe>
<img src="https://w.wiki/64tg" />
<div class="takespace"></div>
<img src="https://w.wiki/64tg" />
<div class="takespace"></div>
</content-container>
I've tested this on Firefox 107.0.1 and Chrome 108.0.5359.73; Firefox added support for backdrop-filter back in version 103 (though I haven't gone back and tested it in that or prior versions). I've tried adding wrappers and z-index settings surrounding the embeds, using a ::before pseudo-element to contain the backdrop-filter, and more. So far nothing I've done has caused the backdrop-filter to behave as expected on firefox. Obviously I can just run code to detect that someone is using Firefox and set the element to be fully opaque, but I'd like to avoid querying useragent if possible (feature detection wouldn't work, since Firefox has the feature). If there's a way to get this working properly in FF I'd like to know.
Before someone marks this as a duplicate, I do not believe this is related to z-index behaviour is different in chrome to firefox. Current firefox behavior mimics chrome in this aspect, fixed positioning is not used, and the navbar still shows up above other elements as expected.
As of Firefox version 108 backdrop filter behavior is working. Nothing in the patch notes suggests that this behavior was directly addressed, but the fact that it changed between versions suggests that it was a bug fixed by some other change (see https://bugzilla.mozilla.org/show_bug.cgi?id=1794432 for the bug it appears to be related to). It's very probable it was a bug.
I'm working with a website (Gatsby) with a sticky bar at the bottom on one page. I'm using position: sticky to stick the bar to the bottom of the screen. However, this works on all other mobile browsers but Chrome in iOS.
Scenario:
First page: This page has a list. When clicked on an item, it will open the second page in a new tab.
Second page: This is the page with the sticky bar and this opens in a new tab.
Issue: When I go to the first page, click on the item, and goes to the second page which opens in a new tab, the sticky bar gets covered from the bottom toolbar. However, if you click on the second page's link directly and visit it, the sticky bar works fine.
Has anyone of you encountered something like this before? Can this be a bug in iOS Chrome or am I doing something wrong?
Code I'm using for the sticky bar:
.floating-bar {
display: flex;
position: sticky;
align-items: center;
justify-content: space-between;
padding: 0 25px;
bottom: 0;
left: 0;
z-index: 10;
width: 100%;
box-sizing: border-box;
background: white;
border-top: 1px solid #dfe1e6;
height: 60px;
overflow: hidden;
// + some paddings based on the viewport
}
Please see the below gifs as a reference.
Visiting from the first page: https://ibb.co/6yMLLm3
Direct visit using the URL: https://ibb.co/Mp1rknm
This isn't a full answer as it doesn't have a workaround (as yet!) but I put this finding here in case it helps us get nearer the solution.
Try running these two bits of code. The first takes you the site without a `target="_blank" in the a element - i.e. it stays in the same browser tab. The second has the target attribute so opens a new tab. The first shows the sticky div correctly, the second only when the user has scrolled.
No target - works OK:
goto site
With target - doesn't work OK
goto site
(can't run it as a snippet it seems).
There is a target="_blank" in the first page code and this seems to cause Chrome IOS to malfunction.
Update: while the problem discussed in this post is not the same, it does seem people were having problems with target_blank in Chrome on IOS, including in one case removing the target_blank to get round the problem. See https://support.google.com/chrome/thread/10249317?hl=en
Some of the computers in the office has already updated their Google Chrome Browsers. I am currently on Version 38.0.2125.111 m. The website we have was built with XHTML 1.0. I haven't made any changes to the website, but all of a sudden the left positioning I have set at 800px is now more left than it should be.
I know it was the update to Google Chrome, because not everybody has this issue with outdated versions. I also checked it on Chrome Canary and it does the same thing. I cross checked the website with IE 10 and it seems to render it just fine. Right now I have some text that is overlapping with another DIV (search box). Here is the problem part. I could just add more left PX, but I wanted to know why it changed and maybe what would be better way so this doesn't happen again.
<div style="left: 800px; height: 30px; position: absolute; top: 50%; margin-top: -11px;
z-index: 1;">
<a id="HyperLink1" href="#" style="color:Yellow;font-style:italic;">Logout</a>
</div>
I don't know why Google Chrome has changed the way of positioning, but to avoid it and other futures modifications, I suggest you to use a CSS reset, which assure you you'll have 'standart' initial CSS properties on every browsers.
I am making a HTML/CSS and jQuery-based file manager aimed at mobile devices. Part of it involves the use of CSS=based modal dialog boxes for various file operations (copy, delete etc.).
I achieve the modal dialog behaviour like this:
<div id="overlay">
<div id="modalBoxControls">[close]</div>
<div id="modalBox">
<div id="modalBoxContent"></div>
</div>
</div>
And the CSS is:
#overlay {
position: fixed;
left: 0px;
top: 0px;
width:100%;
height:100%;
text-align:center;
z-index: 1000;
background: ([semi-transparent png]);
display: none;
}
#modalBox {
width: 80%;
background-color: #fff;
margin: 0px auto;
opacity: 1;
}
I use jQuery to show and hide it by calling .fadeIn() and .fadeOut() on the overlay element.
So far so good - this works great in all the browsers on my dev machine.
However, when testing on my WP7 (Samsung Omnia 7), a rather bizarre thing happens. The modal dialog shows up fine, the page behind it is blacked out. But clicks (or taps) go through the #overlay and activate anything behind it, even though it totally covers up everything behind and it's z-index is 1000.
I also tested this with the well-known "Lightview" plugin from Nick Stakenburg (a well-tested and refined piece of code) and found the same behaviour on IE on WP7.
So it seems like this could be a bug with the browser itself.
Does anyone know any solution for this?
Edit - jsFiddle with example of problem
So, check this out in your WP7 device and see how the files can still be clicked even when there is an overlay over the top of them: http://jsfiddle.net/michaelbromley/CHU76/
If by "activate anything behind it" means input controls like text input then I had the same issue. To be honesty I don't know a good solution. My workaround was disabling input controls during popup is showed and then activating them back by removing disabled attribute. The problem seems not to be related to jqmobile, but supposed to be a general behavior.
OK, so it seems that there may be no "proper" solution to this problem (hey, 24 hours is a long time on SO!), so I have come up with my own hack solution:
I when the modal dialog box is opened, I simultaneously set the "visibility" CSS property of all the elements "behind" the overlay (i.e. links and anything else that would otherwise erroneously respond to taps/clicks) to "hidden" (by using jQuery's .css() function). This means that the page layout is not affected, and that there is now nothing there to be clicked on.
As I said, this is a bit of a hack and will not be suitable for everyone who runs into this problem. However, it works well for me.
Code in jsFiddle: http://jsfiddle.net/michaelbromley/CHU76/1/
Yes, this is clearly a bug in Window Phone 7 and it is not even fixed in Windows Phone 10.
I will report this bug to Microsoft and hopefully it will be fixed.
I'm working on my new online portfolio at http://asbjorn.org/ny/, and I've come across the weirdest issue!
Every time you open the page for the first time, the next and previous buttons for the slideshow don't appear. If I open the inspector, they pop up immediately, and they also appear when reloading the page.
They're pretty standard html elements, not added dynamically, so I have NO clue as to why this happens! Of course I can't have the site visitors reload the page just to see them. :/
I really hope someone can help me! :)
update: seems like it's a chrome only issue. For me it happens consistently in chrome on both Win7 and OSX. A few of my friends also has the same issue (probably in chrome on osx)
So I'll take a stab at an answer. When I see the problem in Chrome 22, and I bring up the inspector, I note that the #previousLink and #nextLink divs have a width of 0 in the broken state. Try setting an explicit width for these in your CSS, or make the nested image use display: block.
#previousLink { width: 31px; }
#nextLink { width: 37px; }
or
#previousLink img,
#nextLink img { display: block; }
I think the combination of these inline items and your overflow: hidden rule are biting you. I think. This is a tricky bug!