Responsive mode ignores '_blank' targets

Developer Tools
#1

I’ve tried repeatedly to open a page in responsive design mode in the 64bit Dev Edition (v. 56.0b6) where it contains a href link with a target of ‘_blank’ - and when the link is clicked, the new window won’t open and the target is totally ignored. Regular, non-targeted links work fine in responsive mode, and they all work fine when the browser isn’t using responsive mode and opened to a desktop page layout.

Using standard FF 64bit v. 55.02, everything works as expected in either desktop or responsive mode.

I’m also having random CSS and javascript issues where some things won’t show at all… like forward/reverse arrows in lightboxes and overlays when in responsive mode in the Dev Edition.

Is anyone else experiencing the same type of things? Are there multiple issues with devtools that need some serious attention? I’m not about to jump away from using the non-dev browser if it’s the only version that’s stable enough to use.

#2

Thanks for bringing this issue with <a target="_blank"></a> to our attention! As far as I know, you are the first to report it. I can confirm it’s not working inside RDM in 56 and later. I filed bug 1394473 about this.

As for the CSS / JS issues you mention, I haven’t heard about anything like that. Can you provide more details? Can you share a sample page that demonstrates the issue?

#3

Thanks for confirming the target issue, and good to know it’s in the queue.

As for the CSS/JS issues, I’ve managed to pin down what appeared to be the random behavior to something specific and repeatable. I don’t have a public page of my own to point you to, but the same components are also used here: http://portfolio.bixie.org/portfolio

If you visit the page with 56.06b and toggle to responsive mode with touch enabled - then click an image in the portfolio section to open an image slider as a lightbox… you’ll get the expected behavior at first. Now toggle the touch control to turn it off, and you won’t get the backward/forward arrows for the ‘desktop version’; and obviously, touch/click no longer works. The only choice is to close an image, open another, close, it, etc., since there’s no slider controls or a slideshow script to auto-play or to toggle one on.

Now toggle responsive mode off to get back to desktop mode… and most likely there’s still no arrows if you go through the same steps. You’ll need to manually refresh the page to ‘reset’ all the toggles. It also won’t matter what device emulation you choose… they all produce the same series of problems.

Going through the same set of steps in FF 55.02 w/DevTools enabled gives all the expected responses, albeit not in an ‘automatically refreshed’ way since it won’t reload the page when first toggled into touch mode by default.

I haven’t gone through the script/CSS to verify there isn’t some errors within them that’s causing these problems, as I’m not the developer - but - if there’s a coding issue there, wouldn’t 55.02 also show the same type of issues? It all seems tied to responsive mode’s code in the Dev Edition.

#4

After re-reading my last post, I should clarify the part about clicking “in the portfolio section”.

In the linked screengrab it shows RDM set up for a Google Nexus 7 as a reference. If you click one of the images in the green oval, you’d get the issue as-described. If you click the ‘hero’ image in the orange oval, it will take you to a new individual portfolio page - and then - clicking any of the lower images shown there will produce the same issues on the newly opened page. Same issues with the same images/script/css - just on a deeper page.

https://www.dropbox.com/s/tpdwx0yq84h8o7z/devtools-portfolio-glitch.jpg?dl=0

#5

Hmm. Currently when you disable touch in the latest RDM, it doesn’t reload the page, so there’s no way for the page to realize something has changed (as far as I can tell).

So, if a page is hiding controls when touch is available, they would stay hidden after disabling touch until the page is manually reloaded, which sounds like what you are seeing.

Would you prefer RDM to also automatically reload when disabling touch?

#6

Well… I think my expectation is that when I toggle the state of a control when it has only 2 states - that the functions available within the currently rendered display will all match up to the state of the toggled control(s).

In other words, when RDM is toggled on, it changes the rendered display properties according to those of the selected device - be it a phone or tablet, etc. As it gets toggled off, the rendered display would be reset to use the ‘desktop’ properties of the browser. When touch is toggled on, it causes the mouse to act as a finger would on a touch-enabled device - and when it’s toggled off, the entire function set of RDM should be reset to that of a non-touch device and a mouse is again, just a mouse.

Whether all of this means a simple reload of the page itself is needed with each toggle action, or some internal ‘reset’ of RDM’s functions with each change of state… the idea should be for everything within the chosen display setup to be in context and match the currently set state of all the toggles. I’d think that DevTools would mirror the functionality of a specific device without secondary choices being made as anyone uses the tools, whether that’s resetting a bunch of toggles or reloading pages whenever toggles get changed.

Personally, I would prefer to concentrate on using the tools at hand without having to constantly check the ‘correctness’ of how they’re set up.

#7

The original thinking around skipping reloads in certain cases was to avoid losing state in a complex application that might take time to reconstruct.

Looking at other tools like the Chrome’s device mode, they never force reloading (enabling or disabling touch), even though it’s still needed for the page to be completely accurate in their tools as well. So you’d have to know to keep refreshing every time.

I believe in all cases the tools are doing what they should immediately after you disable touch simulation, but it’s just that the page doesn’t know that. It can cache the touch mode at load time, for example.

I don’t think we’ve had any complaints about the auto-reload when entering touch mode, and I think you’ve convinced me that the potential for confusion outweighs the possible state loss of reloading. Also, the fact that we auto-reload only for one of the two transitions is potentially the most confusing mode (more than always reloading or never reloading for both).

I filed bug 1398297 about this. Thanks for the feedback!