Limitations of Fibr Editor

fibr editor is powerful, but it has boundaries understanding these limitations upfront helps you plan better and avoid frustration for most cases, there's a workaround or alternative approach browser limitations chrome only fibr editor runs as a chrome extension it doesn't work in firefox, safari, edge, or other browsers make sure your team uses chrome when creating or editing variants extension must be active the editor only works when the chrome extension is installed and you're signed in if you're having issues, check that the extension is enabled and you're logged into the correct workspace element limitations some elements can't be edited fibr works with standard html elements, but certain elements may not be editable elements loaded dynamically via javascript after page load content inside iframes (like embedded videos or third party widgets) elements with heavy javascript manipulation (e g , some react or vue components) canvas elements and webgl content content generated by third party scripts workaround for elements fibr can't select, use the html edit feature to target them directly, or work with your development team to make those elements accessible complex single page applications (spas) websites built entirely with react, angular, or vue may have limited compatibility fibr works best when the dom structure is stable if your site heavily manipulates the dom after load, some edits may not persist correctly workaround test thoroughly in preview mode for spa heavy sites, consider having developers expose stable container elements that fibr can target reliably styling limitations inherited styles may override changes if your site uses css with high specificity or !important declarations, fibr's style changes might not take effect the editor applies inline styles, which can be overridden by aggressive css rules workaround use html edit mode to add inline styles with !important, or work with your development team to reduce css specificity on elements you want to personalize custom fonts require availability you can change font families, but the font must be already loaded on your page or available as a web safe font fibr doesn't upload or host custom fonts workaround ask your development team to load any additional fonts you need in the site's css, then reference them in fibr functional limitations no backend changes fibr modifies the front end presentation layer only it cannot change server side logic or api responses modify database content alter form submission destinations affect authentication or user sessions workaround for backend dependent personalization, work with your development team to create front end hooks that fibr can trigger no cross page persistence edits apply to individual pages if you change a header on page a, it won't automatically change on page b, even if they share the same template workaround use fibr's bulk editing feature to apply similar changes across multiple pages efficiently limited form modification you can edit form labels, placeholder text, and styling however, you cannot add new form fields that submit data change where form data is sent modify form validation logic workaround use widgets to add supplementary lead capture forms that integrate with fibr's tracking performance considerations very large pages may slow the editor pages with thousands of dom elements or heavy media content can make the editor less responsive the live page won't be affected, but editing may feel sluggish workaround close unnecessary browser tabs, or edit on a simplified staging version of the page first multiple conflicting tools if you're running other visual editing tools, heatmapping scripts, or optimization platforms simultaneously, they may conflict with fibr workaround disable other visual editing tools while using fibr editor they can run alongside fibr in production without issues; conflicts mainly occur during editing use case why it doesn't fit alternative building pages from scratch fibr edits existing pages use fibr genesis to create new landing pages major site redesigns too many interdependent changes work with developers for structural changes e commerce product data product info comes from backend use your e commerce platform's tools dynamic user specific content requires backend personalization integrate with your cdp for data driven personalization when to involve developers fibr editor handles most marketing driven changes independently but some scenarios benefit from developer support making elements "fibr friendly" for easier targeting loading additional fonts or assets you want to use creating stable container elements in spas setting up backend integrations for advanced personalization resolving css specificity conflicts a small amount of developer time upfront can significantly expand what you can do with fibr independently