How to release keyboard and mouse from grab by a hung unkillable app? [duplicate]












11
















This question already has an answer here:




  • Command for forcing a pointer ungrab (captured mouse release)

    3 answers




Suppose I have an X application, which grabs keyboard and mouse as its normal mode of operation (e.g. QEMU), but which, due to a bug somewhere, hangs really hard (e.g. gets stuck in Disk sleep). Normally I'd kill an app using kill(1) from a remote terminal, but if the app is in Disk sleep mode, it can't really be killed. I could kill this app's connection to X server by the xkill utility, but this time I can't do this because mouse is grabbed, so xkill will fail to run.



So, how do I release my keyboard and mouse from grab by an X client, if I'm willing to sacrifice this client, but am unable to kill it by the OS means?






x11 keyboard







share|improve this question













marked as duplicate by mosvy, Stephen Harris, roaima, Networker, Christopher yesterday


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
















  • A related question is unix.stackexchange.com/questions/494180 .

    – JdeBP
    2 days ago











  • also unix.stackexchange.com/questions/23164/…

    – mosvy
    2 days ago
















11
















This question already has an answer here:




  • Command for forcing a pointer ungrab (captured mouse release)

    3 answers




Suppose I have an X application, which grabs keyboard and mouse as its normal mode of operation (e.g. QEMU), but which, due to a bug somewhere, hangs really hard (e.g. gets stuck in Disk sleep). Normally I'd kill an app using kill(1) from a remote terminal, but if the app is in Disk sleep mode, it can't really be killed. I could kill this app's connection to X server by the xkill utility, but this time I can't do this because mouse is grabbed, so xkill will fail to run.



So, how do I release my keyboard and mouse from grab by an X client, if I'm willing to sacrifice this client, but am unable to kill it by the OS means?






x11 keyboard







share|improve this question













marked as duplicate by mosvy, Stephen Harris, roaima, Networker, Christopher yesterday


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
















  • A related question is unix.stackexchange.com/questions/494180 .

    – JdeBP
    2 days ago











  • also unix.stackexchange.com/questions/23164/…

    – mosvy
    2 days ago














11












11








11


4







This question already has an answer here:




  • Command for forcing a pointer ungrab (captured mouse release)

    3 answers




Suppose I have an X application, which grabs keyboard and mouse as its normal mode of operation (e.g. QEMU), but which, due to a bug somewhere, hangs really hard (e.g. gets stuck in Disk sleep). Normally I'd kill an app using kill(1) from a remote terminal, but if the app is in Disk sleep mode, it can't really be killed. I could kill this app's connection to X server by the xkill utility, but this time I can't do this because mouse is grabbed, so xkill will fail to run.



So, how do I release my keyboard and mouse from grab by an X client, if I'm willing to sacrifice this client, but am unable to kill it by the OS means?






x11 keyboard







share|improve this question















This question already has an answer here:




  • Command for forcing a pointer ungrab (captured mouse release)

    3 answers




Suppose I have an X application, which grabs keyboard and mouse as its normal mode of operation (e.g. QEMU), but which, due to a bug somewhere, hangs really hard (e.g. gets stuck in Disk sleep). Normally I'd kill an app using kill(1) from a remote terminal, but if the app is in Disk sleep mode, it can't really be killed. I could kill this app's connection to X server by the xkill utility, but this time I can't do this because mouse is grabbed, so xkill will fail to run.



So, how do I release my keyboard and mouse from grab by an X client, if I'm willing to sacrifice this client, but am unable to kill it by the OS means?





This question already has an answer here:




  • Command for forcing a pointer ungrab (captured mouse release)

    3 answers







x11 keyboard




x11 keyboard






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 2 days ago









RuslanRuslan

1,3071225




1,3071225




marked as duplicate by mosvy, Stephen Harris, roaima, Networker, Christopher yesterday


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.






marked as duplicate by mosvy, Stephen Harris, roaima, Networker, Christopher yesterday


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.















  • A related question is unix.stackexchange.com/questions/494180 .

    – JdeBP
    2 days ago











  • also unix.stackexchange.com/questions/23164/…

    – mosvy
    2 days ago



















  • A related question is unix.stackexchange.com/questions/494180 .

    – JdeBP
    2 days ago











  • also unix.stackexchange.com/questions/23164/…

    – mosvy
    2 days ago

















A related question is unix.stackexchange.com/questions/494180 .

– JdeBP
2 days ago





A related question is unix.stackexchange.com/questions/494180 .

– JdeBP
2 days ago













also unix.stackexchange.com/questions/23164/…

– mosvy
2 days ago





also unix.stackexchange.com/questions/23164/…

– mosvy
2 days ago










3 Answers
3






active

oldest

votes


















13














Although the most well-known use mode of xkill is "click to kill", there's an option -id, which can be supplied with Window Id of the client you want to disconnect from X server. Then, if you can access your X session from a remote terminal/VT, you can use xprop or some other means to get the Id, and pass it to xkill.



Suppose that current active window belongs to the X client who grabbed the keys&mouse. Then the following will kill this client's connection to the X server and thus release keyboard and mouse from the grab:



winid=$(xprop -root _NET_ACTIVE_WINDOW | cut -d# -f2)

xkill -id $winid


This actually worked for me when I tried to get rid of QEMU's grab when QEMU was stuck in Disk sleep.






share|improve this answer





















  • 2





    One caveat to notice is that xkill on a hung window is not guaranteed to kill the process. It's quite possible for a process to be stuck so badly it won't notice that its window is gone. Still sometimes it's useful enough to get rid of the window first and deal with the process later.

    – kasperd
    2 days ago











  • of course the process won't notice anything if it's in an uninterruptible sleep; if it ever wakes up, it may die with an X11 error; that's why it's much better to force release its grabs (as in the linked q&a's) than cutting short its connection to the X11 server with xkill/XKillClient.

    – mosvy
    2 days ago



















2














You could try the standard SysRq+R trick which should release the keyboard from the X server, or the Ctrl+Alt+1-6 combination that changes the current console, maybe allowing you to run a terminal and kill the faulty program.






share|improve this answer








New contributor




zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • And how do I re-attach keyboard back to the X server? Isn't this as useful as Ctrl+Alt+Backspace?

    – Ruslan
    2 days ago













  • I don't know how you could re-attach it to X, but it would at least allow you to kill the process that's locking the input

    – zdimension
    2 days ago






  • 2





    Wait, you imply killing it via kill(1) or similar. This doesn't work, as described in the OP. And anyway, simply killing the process (even if it worked) isn't enough: the aim is to re-gain control via keyboard, while this answer removes this control from the whole X server instead.

    – Ruslan
    2 days ago






  • 2





    @Ruslan I think the keyboard should re-attach if you switch to another VT and back to the X server. But as you pointed out, it doesn't help if you cannot kill the process. The use of SysRq + R is really only useful if you cannot use a remote terminal (for example if networking or sshd is down).

    – kasperd
    2 days ago











  • OK, re-attachment happens automatically when I switch back to X server's VT — just checked. Still, using the OS means of killing the process makes this not-an-answer.

    – Ruslan
    2 days ago





















-4














kill -9 often works when plain kill does not.






share|improve this answer








New contributor




Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 5





    See the OP: no signal will kill an app which is in Disk sleep. Besides, kill -9 is still kill(1).

    – Ruslan
    2 days ago




















3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









13














Although the most well-known use mode of xkill is "click to kill", there's an option -id, which can be supplied with Window Id of the client you want to disconnect from X server. Then, if you can access your X session from a remote terminal/VT, you can use xprop or some other means to get the Id, and pass it to xkill.



Suppose that current active window belongs to the X client who grabbed the keys&mouse. Then the following will kill this client's connection to the X server and thus release keyboard and mouse from the grab:



winid=$(xprop -root _NET_ACTIVE_WINDOW | cut -d# -f2)

xkill -id $winid


This actually worked for me when I tried to get rid of QEMU's grab when QEMU was stuck in Disk sleep.






share|improve this answer





















  • 2





    One caveat to notice is that xkill on a hung window is not guaranteed to kill the process. It's quite possible for a process to be stuck so badly it won't notice that its window is gone. Still sometimes it's useful enough to get rid of the window first and deal with the process later.

    – kasperd
    2 days ago











  • of course the process won't notice anything if it's in an uninterruptible sleep; if it ever wakes up, it may die with an X11 error; that's why it's much better to force release its grabs (as in the linked q&a's) than cutting short its connection to the X11 server with xkill/XKillClient.

    – mosvy
    2 days ago
















13














Although the most well-known use mode of xkill is "click to kill", there's an option -id, which can be supplied with Window Id of the client you want to disconnect from X server. Then, if you can access your X session from a remote terminal/VT, you can use xprop or some other means to get the Id, and pass it to xkill.



Suppose that current active window belongs to the X client who grabbed the keys&mouse. Then the following will kill this client's connection to the X server and thus release keyboard and mouse from the grab:



winid=$(xprop -root _NET_ACTIVE_WINDOW | cut -d# -f2)

xkill -id $winid


This actually worked for me when I tried to get rid of QEMU's grab when QEMU was stuck in Disk sleep.






share|improve this answer





















  • 2





    One caveat to notice is that xkill on a hung window is not guaranteed to kill the process. It's quite possible for a process to be stuck so badly it won't notice that its window is gone. Still sometimes it's useful enough to get rid of the window first and deal with the process later.

    – kasperd
    2 days ago











  • of course the process won't notice anything if it's in an uninterruptible sleep; if it ever wakes up, it may die with an X11 error; that's why it's much better to force release its grabs (as in the linked q&a's) than cutting short its connection to the X11 server with xkill/XKillClient.

    – mosvy
    2 days ago














13












13








13







Although the most well-known use mode of xkill is "click to kill", there's an option -id, which can be supplied with Window Id of the client you want to disconnect from X server. Then, if you can access your X session from a remote terminal/VT, you can use xprop or some other means to get the Id, and pass it to xkill.



Suppose that current active window belongs to the X client who grabbed the keys&mouse. Then the following will kill this client's connection to the X server and thus release keyboard and mouse from the grab:



winid=$(xprop -root _NET_ACTIVE_WINDOW | cut -d# -f2)

xkill -id $winid


This actually worked for me when I tried to get rid of QEMU's grab when QEMU was stuck in Disk sleep.






share|improve this answer















Although the most well-known use mode of xkill is "click to kill", there's an option -id, which can be supplied with Window Id of the client you want to disconnect from X server. Then, if you can access your X session from a remote terminal/VT, you can use xprop or some other means to get the Id, and pass it to xkill.



Suppose that current active window belongs to the X client who grabbed the keys&mouse. Then the following will kill this client's connection to the X server and thus release keyboard and mouse from the grab:



winid=$(xprop -root _NET_ACTIVE_WINDOW | cut -d# -f2)

xkill -id $winid


This actually worked for me when I tried to get rid of QEMU's grab when QEMU was stuck in Disk sleep.







share|improve this answer














share|improve this answer



share|improve this answer








edited 2 days ago

























answered 2 days ago









RuslanRuslan

1,3071225




1,3071225








  • 2





    One caveat to notice is that xkill on a hung window is not guaranteed to kill the process. It's quite possible for a process to be stuck so badly it won't notice that its window is gone. Still sometimes it's useful enough to get rid of the window first and deal with the process later.

    – kasperd
    2 days ago











  • of course the process won't notice anything if it's in an uninterruptible sleep; if it ever wakes up, it may die with an X11 error; that's why it's much better to force release its grabs (as in the linked q&a's) than cutting short its connection to the X11 server with xkill/XKillClient.

    – mosvy
    2 days ago














  • 2





    One caveat to notice is that xkill on a hung window is not guaranteed to kill the process. It's quite possible for a process to be stuck so badly it won't notice that its window is gone. Still sometimes it's useful enough to get rid of the window first and deal with the process later.

    – kasperd
    2 days ago











  • of course the process won't notice anything if it's in an uninterruptible sleep; if it ever wakes up, it may die with an X11 error; that's why it's much better to force release its grabs (as in the linked q&a's) than cutting short its connection to the X11 server with xkill/XKillClient.

    – mosvy
    2 days ago








2




2





One caveat to notice is that xkill on a hung window is not guaranteed to kill the process. It's quite possible for a process to be stuck so badly it won't notice that its window is gone. Still sometimes it's useful enough to get rid of the window first and deal with the process later.

– kasperd
2 days ago





One caveat to notice is that xkill on a hung window is not guaranteed to kill the process. It's quite possible for a process to be stuck so badly it won't notice that its window is gone. Still sometimes it's useful enough to get rid of the window first and deal with the process later.

– kasperd
2 days ago













of course the process won't notice anything if it's in an uninterruptible sleep; if it ever wakes up, it may die with an X11 error; that's why it's much better to force release its grabs (as in the linked q&a's) than cutting short its connection to the X11 server with xkill/XKillClient.

– mosvy
2 days ago





of course the process won't notice anything if it's in an uninterruptible sleep; if it ever wakes up, it may die with an X11 error; that's why it's much better to force release its grabs (as in the linked q&a's) than cutting short its connection to the X11 server with xkill/XKillClient.

– mosvy
2 days ago













2














You could try the standard SysRq+R trick which should release the keyboard from the X server, or the Ctrl+Alt+1-6 combination that changes the current console, maybe allowing you to run a terminal and kill the faulty program.






share|improve this answer








New contributor




zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • And how do I re-attach keyboard back to the X server? Isn't this as useful as Ctrl+Alt+Backspace?

    – Ruslan
    2 days ago













  • I don't know how you could re-attach it to X, but it would at least allow you to kill the process that's locking the input

    – zdimension
    2 days ago






  • 2





    Wait, you imply killing it via kill(1) or similar. This doesn't work, as described in the OP. And anyway, simply killing the process (even if it worked) isn't enough: the aim is to re-gain control via keyboard, while this answer removes this control from the whole X server instead.

    – Ruslan
    2 days ago






  • 2





    @Ruslan I think the keyboard should re-attach if you switch to another VT and back to the X server. But as you pointed out, it doesn't help if you cannot kill the process. The use of SysRq + R is really only useful if you cannot use a remote terminal (for example if networking or sshd is down).

    – kasperd
    2 days ago











  • OK, re-attachment happens automatically when I switch back to X server's VT — just checked. Still, using the OS means of killing the process makes this not-an-answer.

    – Ruslan
    2 days ago


















2














You could try the standard SysRq+R trick which should release the keyboard from the X server, or the Ctrl+Alt+1-6 combination that changes the current console, maybe allowing you to run a terminal and kill the faulty program.






share|improve this answer








New contributor




zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • And how do I re-attach keyboard back to the X server? Isn't this as useful as Ctrl+Alt+Backspace?

    – Ruslan
    2 days ago













  • I don't know how you could re-attach it to X, but it would at least allow you to kill the process that's locking the input

    – zdimension
    2 days ago






  • 2





    Wait, you imply killing it via kill(1) or similar. This doesn't work, as described in the OP. And anyway, simply killing the process (even if it worked) isn't enough: the aim is to re-gain control via keyboard, while this answer removes this control from the whole X server instead.

    – Ruslan
    2 days ago






  • 2





    @Ruslan I think the keyboard should re-attach if you switch to another VT and back to the X server. But as you pointed out, it doesn't help if you cannot kill the process. The use of SysRq + R is really only useful if you cannot use a remote terminal (for example if networking or sshd is down).

    – kasperd
    2 days ago











  • OK, re-attachment happens automatically when I switch back to X server's VT — just checked. Still, using the OS means of killing the process makes this not-an-answer.

    – Ruslan
    2 days ago
















2












2








2







You could try the standard SysRq+R trick which should release the keyboard from the X server, or the Ctrl+Alt+1-6 combination that changes the current console, maybe allowing you to run a terminal and kill the faulty program.






share|improve this answer








New contributor




zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.










You could try the standard SysRq+R trick which should release the keyboard from the X server, or the Ctrl+Alt+1-6 combination that changes the current console, maybe allowing you to run a terminal and kill the faulty program.







share|improve this answer








New contributor




zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this answer



share|improve this answer






New contributor




zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









answered 2 days ago









zdimensionzdimension

1293




1293




New contributor




zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.













  • And how do I re-attach keyboard back to the X server? Isn't this as useful as Ctrl+Alt+Backspace?

    – Ruslan
    2 days ago













  • I don't know how you could re-attach it to X, but it would at least allow you to kill the process that's locking the input

    – zdimension
    2 days ago






  • 2





    Wait, you imply killing it via kill(1) or similar. This doesn't work, as described in the OP. And anyway, simply killing the process (even if it worked) isn't enough: the aim is to re-gain control via keyboard, while this answer removes this control from the whole X server instead.

    – Ruslan
    2 days ago






  • 2





    @Ruslan I think the keyboard should re-attach if you switch to another VT and back to the X server. But as you pointed out, it doesn't help if you cannot kill the process. The use of SysRq + R is really only useful if you cannot use a remote terminal (for example if networking or sshd is down).

    – kasperd
    2 days ago











  • OK, re-attachment happens automatically when I switch back to X server's VT — just checked. Still, using the OS means of killing the process makes this not-an-answer.

    – Ruslan
    2 days ago





















  • And how do I re-attach keyboard back to the X server? Isn't this as useful as Ctrl+Alt+Backspace?

    – Ruslan
    2 days ago













  • I don't know how you could re-attach it to X, but it would at least allow you to kill the process that's locking the input

    – zdimension
    2 days ago






  • 2





    Wait, you imply killing it via kill(1) or similar. This doesn't work, as described in the OP. And anyway, simply killing the process (even if it worked) isn't enough: the aim is to re-gain control via keyboard, while this answer removes this control from the whole X server instead.

    – Ruslan
    2 days ago






  • 2





    @Ruslan I think the keyboard should re-attach if you switch to another VT and back to the X server. But as you pointed out, it doesn't help if you cannot kill the process. The use of SysRq + R is really only useful if you cannot use a remote terminal (for example if networking or sshd is down).

    – kasperd
    2 days ago











  • OK, re-attachment happens automatically when I switch back to X server's VT — just checked. Still, using the OS means of killing the process makes this not-an-answer.

    – Ruslan
    2 days ago



















And how do I re-attach keyboard back to the X server? Isn't this as useful as Ctrl+Alt+Backspace?

– Ruslan
2 days ago







And how do I re-attach keyboard back to the X server? Isn't this as useful as Ctrl+Alt+Backspace?

– Ruslan
2 days ago















I don't know how you could re-attach it to X, but it would at least allow you to kill the process that's locking the input

– zdimension
2 days ago





I don't know how you could re-attach it to X, but it would at least allow you to kill the process that's locking the input

– zdimension
2 days ago




2




2





Wait, you imply killing it via kill(1) or similar. This doesn't work, as described in the OP. And anyway, simply killing the process (even if it worked) isn't enough: the aim is to re-gain control via keyboard, while this answer removes this control from the whole X server instead.

– Ruslan
2 days ago





Wait, you imply killing it via kill(1) or similar. This doesn't work, as described in the OP. And anyway, simply killing the process (even if it worked) isn't enough: the aim is to re-gain control via keyboard, while this answer removes this control from the whole X server instead.

– Ruslan
2 days ago




2




2





@Ruslan I think the keyboard should re-attach if you switch to another VT and back to the X server. But as you pointed out, it doesn't help if you cannot kill the process. The use of SysRq + R is really only useful if you cannot use a remote terminal (for example if networking or sshd is down).

– kasperd
2 days ago





@Ruslan I think the keyboard should re-attach if you switch to another VT and back to the X server. But as you pointed out, it doesn't help if you cannot kill the process. The use of SysRq + R is really only useful if you cannot use a remote terminal (for example if networking or sshd is down).

– kasperd
2 days ago













OK, re-attachment happens automatically when I switch back to X server's VT — just checked. Still, using the OS means of killing the process makes this not-an-answer.

– Ruslan
2 days ago







OK, re-attachment happens automatically when I switch back to X server's VT — just checked. Still, using the OS means of killing the process makes this not-an-answer.

– Ruslan
2 days ago













-4














kill -9 often works when plain kill does not.






share|improve this answer








New contributor




Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 5





    See the OP: no signal will kill an app which is in Disk sleep. Besides, kill -9 is still kill(1).

    – Ruslan
    2 days ago


















-4














kill -9 often works when plain kill does not.






share|improve this answer








New contributor




Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 5





    See the OP: no signal will kill an app which is in Disk sleep. Besides, kill -9 is still kill(1).

    – Ruslan
    2 days ago
















-4












-4








-4







kill -9 often works when plain kill does not.






share|improve this answer








New contributor




Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.










kill -9 often works when plain kill does not.







share|improve this answer








New contributor




Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this answer



share|improve this answer






New contributor




Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









answered 2 days ago









Jonathan DushoffJonathan Dushoff

1




1




New contributor




Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 5





    See the OP: no signal will kill an app which is in Disk sleep. Besides, kill -9 is still kill(1).

    – Ruslan
    2 days ago
















  • 5





    See the OP: no signal will kill an app which is in Disk sleep. Besides, kill -9 is still kill(1).

    – Ruslan
    2 days ago










5




5





See the OP: no signal will kill an app which is in Disk sleep. Besides, kill -9 is still kill(1).

– Ruslan
2 days ago







See the OP: no signal will kill an app which is in Disk sleep. Besides, kill -9 is still kill(1).

– Ruslan
2 days ago





-

Popular posts from this blog

1300-talet

Image
Den här artikeln handlar om hundraårsperioden 1300–1399. För decenniet 1300–1309, se 1300-talet (decennium). .mw-parser-output .infobox{border:1px solid #aaa;background-color:#f9f9f9;color:black;margin:.5em 0 .5em 1em;padding:.2em;float:right;clear:right;width:22em;text-align:left;font-size:88%;line-height:1.6em}.mw-parser-output .infobox td,.mw-parser-output .infobox th{vertical-align:top;padding:0 .2em}.mw-parser-output .infobox caption{font-size:larger}.mw-parser-output .infobox.bordered{border-collapse:collapse}.mw-parser-output .infobox.bordered td,.mw-parser-output .infobox.bordered th{border:1px solid #aaa}.mw-parser-output .infobox.bordered .borderless td,.mw-parser-output .infobox.bordered .borderless th{border:0}.mw-parser-output .infobox-showbutton .mw-collapsible-text{color:inherit}.mw-parser-output .infobox.bordered .mergedtoprow td,.mw-parser-output .infobox.bordered .mergedtoprow th{border:0;border-top:1px solid #aaa;border-right:1px solid #aaa}.mw-parser-output ...
Read more

1300-talet

Image
Den här artikeln handlar om hundraårsperioden 1300–1399. För decenniet 1300–1309, se 1300-talet (decennium). .mw-parser-output .infobox{border:1px solid #aaa;background-color:#f9f9f9;color:black;margin:.5em 0 .5em 1em;padding:.2em;float:right;clear:right;width:22em;text-align:left;font-size:88%;line-height:1.6em}.mw-parser-output .infobox td,.mw-parser-output .infobox th{vertical-align:top;padding:0 .2em}.mw-parser-output .infobox caption{font-size:larger}.mw-parser-output .infobox.bordered{border-collapse:collapse}.mw-parser-output .infobox.bordered td,.mw-parser-output .infobox.bordered th{border:1px solid #aaa}.mw-parser-output .infobox.bordered .borderless td,.mw-parser-output .infobox.bordered .borderless th{border:0}.mw-parser-output .infobox-showbutton .mw-collapsible-text{color:inherit}.mw-parser-output .infobox.bordered .mergedtoprow td,.mw-parser-output .infobox.bordered .mergedtoprow th{border:0;border-top:1px solid #aaa;border-right:1px solid #aaa}.mw-parser-output ...
Read more

Display a custom attribute below product name in the front-end Magento 1.9.3.8

Image
0 I need to display a custom attribute bellow the product name and I don't know how can I call this attribute. I am editing the file /app/design/frontend/templatemela/MAG100219_1/template/catalog/product/view.phtml But how can I call this attribute in php? I tried calling a string echo with the name I put in the attribute, but it didn't work. Code is as below: <div class="page-title product-title"> <h1><?php echo $_helper->productAttribute($_product, $_product->getName(), 'name') ?></h1> </div> <div class="codigoinmetro"> <h2><?php echo $_helper->productAttribute($_product, $_product->getName(), 'registroinmetro') ?></h2> </div> php attrib...
Read more